DNS

Domain Name System (DNS) is the name resolution protocol for TCP/IP networks, such as the Internet. A DNS server hosts the information that enables client computers to resolve memorable, alphanumeric DNS names to the IP addresses that computers use to communicate with each other.

  • Before you begin using this computer as a DNS server, see Checklists.
  • To find features that have been moved in the Microsoft® Windows® Server 2003 family, see New ways to do familiar tasks.
  • For tips about using DNS, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.


Checklists

  • Checklist: Installing a DNS server
  • Checklist: Configuring a DNS server
  • Checklist: Deploying DNS
  • Checklist: Deploying DNS for Active Directory
  • Checklist: Verifying DNS before installing Active Directory
  • Checklist: Securing your DNS Infrastructure


Checklist: Installing a DNS server

Step | Reference
If you are new to working with Domain Name System (DNS), first learn the basic DNS concepts and then examine how to use DNS-related tools to deploy and maintain the client and server features of DNS. | DNS overview
Learn in more detail about how DNS works and understand more about DNS-related features. | Understanding DNS; Deploying DNS; Administering DNS
Before installing a DNS server, determine if the server is now a domain controller or whether it will be promoted to one later. | Server planning for DNS; DNS considerations for Active Directory
Install the first DNS server on your network. If you want to install Active Directory, the Active Directory Installation Wizard will automatically prompt you to install a DNS server. Otherwise, you can install the DNS Server service as a Windows component. | To install a DNS server
Select the checklist that best describes your deployment needs and follow it to complete your DNS installation. | Checklist: Configuring a DNS server; Checklist: Deploying DNS; Checklist: Deploying DNS for Active Directory


Checklist: Configuring a DNS server

Step | Reference
If you have not installed a DNS server, first follow the DNS server installation checklist, and then return to this checklist to configure your new DNS server. | Checklist: Installing a DNS server

For small office/home office. If you are setting up a home network with multiple machines connecting to the Internet, have the following on hand:

  • The name of the zone for which this server will be authoritative
  • The IP address of your ISP's DNS server
 Understanding zones and zone transfer; Dynamic update; Using forwarders
For medium office/large office. If the DNS server will service requests from clients on a local network that may or may not be available from the internet, have the following on hand:
  • The name of the zone for which this server will be authoritative
  • Possibly:
    • The name of a reverse lookup zone
    • The IP address of a DNS server used for forwarding
 Server planning for DNS; Zone planning for DNS; Reverse lookup; Using forwarders; Active Directory integration
Before configuring your DNS server, learn DNS server best practices, server features, and the concepts involved in configuring primary and secondary servers. | Server best practices; Server features; Configuring a new primary server; Using secondary servers
Configure your DNS server. | To configure a new DNS server
Verify the DNS server's configuration. | Verifying server configuration


Checklist: Deploying DNS

Step | Reference
Review best practices and all planning issues specific to deploying Domain Name System (DNS) servers on your network when not additionally deploying Active Directory. | Deploying DNS; Best practices
Plan your namespace by specifying a domain name standard for your organization. | Namespace planning for DNS
Plan how to divide up your DNS domain name and network address space into forward and reverse lookup zones as needed. | Zone planning for DNS; Reverse lookup
Plan your DNS servers, such as determining how many servers you need to use and where to put them on your network. | Server planning for DNS
(Optional) Test and evaluate server performance using DNS performance optimizing and monitoring tools. | Monitoring and optimizing servers
Review migration and interoperability issues, if appropriate. | Migrating servers; Interoperability issues
If clients on your network need to be able to resolve external DNS names, consider the use of forwarders for your network. | Using forwarders; To configure a DNS server to use forwarders
Register your organization's domain name with the Internet domain name registrar. This name is used to form the DNS names your organization uses on the Internet.

Internet DNS

Name: ____________________._____

Note

  • Registering a parent or second-level DNS domain name for your organization with an active Internet domain name registration authority is only required if you plan to use this name externally on the Internet.
 Namespace planning for DNS; Interoperability issues
Determine how to manage DNS client resolver configurations. | Managing clients
Begin adding and configuring zones for your first DNS server. | To configure a new DNS server; To add a forward lookup zone; To add a reverse lookup zone
Install and configure additional DNS servers if they are to be used as secondary servers for your initial zones. | To install a DNS server; To add a secondary server for an existing zone; Using secondary servers
(For primary zones only) If the previous step was used, add additional secondary servers for your existing zones to the name server (NS) record to make them authoritative for the zone. | To specify other DNS servers as authoritative for a zone
(Optional) Install any additional zones (and DNS servers) for subdomains you want to delegate away from your first DNS server and its zones. | To configure a new DNS server; Configuring a new primary server
If the previous step was used, add delegations in parent zones for any subdomains added based on the previous step.

For example, if adding sub.example.microsoft.com as a new DNS domain, you would need to add to it a delegation at the example.microsoft.com zone.

 To create a zone delegation; Delegating zones
Add DNS resource records--such as A, PTR, CNAME, and MX records--as needed to complete zone configurations. | Managing resource records; To add a resource record to a zone; Resource records reference
Enable or disable dynamic updates for zones as needed. | To allow dynamic updates; Dynamic update
(Optional) Enable WINS lookup for selected zones. | To enable DNS to use WINS resolution; WINS lookup integration; Using WINS lookup
(Optional) If you want to push updates to secondary servers for a zone, configure DNS notify at the primary server. | To create and manage a notify list for a zone; Understanding zones and zone transfer
Use the monitoring features of the DNS console, such as simple or recursive query testing, to verify that DNS servers are operating correctly. | Monitor servers
Troubleshoot common DNS-related problems, if needed. | Troubleshooting


Checklist: Deploying DNS for Active Directory

Step | Reference
Review best practices for planning your deployment and use of Active Directory with Domain Name System (DNS). | Best practices (DNS); Best practices (Active Directory)
Understand how Active Directory integration works for DNS servers. | Active Directory integration
Consider additional advanced namespace design issues that can affect DNS namespace planning and use before finalizing your Active Directory namespace plans.

Obtain additional information resources on DNS namespace design available from either the Microsoft Web site or Microsoft Press books before for planning your network.

 DNS namespace planning for Active Directory
Review all planning issues specific to deploying DNS servers on your network for supporting Active Directory. | Deploying DNS
Plan your namespace by specifying a domain name standard for your organization. | Namespace planning for DNS
If necessary, register your organization's domain name with the Internet domain name registrar. This name is then used to form the basis for DNS names your organization uses on the Internet and might also form the basis for names used internally on your intranet as well.

Internet DNS

Name: ____________________._____

Note

  • Registering a parent or second-level DNS domain name for your organization with an active Internet domain name registration authority is only required if you plan to use this name externally on the Internet.
 Choosing your first DNS domain name; Choosing names; Interoperability issues
Plan how to divide up your DNS domain name and network address space into forward and reverse lookup zones as needed. | Zone planning for DNS; Reverse lookup
Plan your DNS servers, such as determining how many servers you need to use and where to put them on your network.

For Active Directory, keep in mind that by default server computers promoted to be domain controllers also operate as DNS servers.

 Server planning for DNS
(Optional) Test and evaluate server performance before finalizing your server plans. To perform DNS server evaluation, use related performance and event monitoring tools. | Monitoring and optimizing servers
Review additional migration and interoperability issues, if appropriate. | Migrating servers; Interoperability issues
If clients on your network need to be able to resolve external DNS names, consider whether you need to configure and use forwarders at DNS servers on your network. | Using forwarders; To configure a DNS server to use forwarders
Determine how to manage DNS client resolver configurations. | Managing clients
If needed, add additional zones for any additional subdomains you need to add and use on your network. | To add a forward lookup zone; To add a reverse lookup zone
(Optional) Modify zone configurations to enable dynamic updates and change zone types to integrate storage of zones in Active Directory. | To allow dynamic updates; To change the zone type; To allow only secure dynamic updates
Install and configure domain controllers (or optionally, additional non-integrated DNS servers) and domains if they are to be used for hosting your zones. | To configure a DNS server for use with Active Directory; To install a DNS server; To configure a new DNS server
As needed, add delegations in parent zones for any subdomains added based on the previous step.

For example, if adding sub.example.microsoft.com as a new Active Directory domain, you would need to add to it a delegation at the example.microsoft.com zone.

 To create a zone delegation; Delegating zones
(For standard primary zones only) Add new DNS servers you need to host your zones to the name server (NS) record at the primary zone/server to make them authoritative for the zone. | To specify other DNS servers as authoritative for a zone
Add DNS resource records--such as A, PTR, CNAME, and MX records--as needed to complete zone configurations. | Managing resource records; To add a resource record to a zone; Resource records reference
(Optional) Enable WINS lookup for selected zones. | To enable DNS to use WINS resolution
(Optional) Install and configure the DNS servers to act as secondary servers for your DNS deployment, if needed. | To install a DNS server; To add a secondary server for an existing zone; Using secondary servers
Use the monitoring features of the DNS console, such as simple or recursive query testing, to verify that DNS servers are operating correctly. | Monitor servers
Troubleshoot DNS-related problems, if needed. | Troubleshooting


Checklist: Verifying DNS before installing Active Directory

Step Reference
Verify that a network connection on the server on which you are installing Active Directory is configured with a DNS server to query for domain names.

If you are installing Active Directory on a server in an existing forest, then the network connection of the server must be configured with one or more DNS servers. If not, then configure the network connection with the IP addresses of one or more DNS servers.

If you are installing Active Directory to create a new forest, and no DNS servers are available on the network, then the Active Directory Installation Wizard can automatically install and configure a local DNS server. The DNS server will be installed on the server where you are running the wizard and the server's preferred DNS server setting will be configured to use the new local DNS server. If you install a local DNS server using the Active Directory Installation Wizard, you may stop using this checklist.

 To configure TCP/IP to use DNS; To create a new forest
Verify DNS resource records.

If you are installing Active Directory on a server in an existing forest, verify that the appropriate service (SRV) resource records and the corresponding address (A) resource records exist in DNS.

Role | SRV resource record
Additional domain controller in an existing domain | _ldap._tcp.dc._mcdcs.ActiveDirectoryDomainDNSName
First domain controller in a new child domain | _ldap._tcp.dc._mcdcs.ParentActiveDirectoryDomainDNSName
First domain controller in a new tree | _ldap._tcp.dc._mcdcs.ForestRootDomainDNSName

If the required SRV and A resource records do not exist in DNS, you can add these records.

 To verify DNS registration for domain controllers using the nslookup command; To add a host (A) resource record to a zone; To add a resource record to a zone
Verify dynamic update and service (SRV) resource record.

Verify that the authoritative DNS zone for the domain controller locator (Locator) DNS resource records allows dynamic updates and that the DNS server hosting the zone supports the DNS service (SRV) resource record. To locate the authoritative DNS zone, you will need to locate the primary DNS server hosting that zone.

If the authoritative DNS zone is not configured to allow dynamic updates, configure the zone to allow dynamic updates.

Notes

  • The authoritative DNS zone for the Locator DNS resource records will have the DNS name of the Active Directory domain or the name of a parent zone. For example, if the DNS name of the Active Directory domain is example.microsoft.com., then the authoritative DNS zone could be one of the following:
    • example.microsoft.com
    • microsoft.com
    • com
  • If you have configured DNS to not dynamically register these resource records in DNS, then these resource records must be added manually. The list of resource records that should be registered by a domain controller are stored in the following location:

    • systemroot\System32\Config\Netlogon.dns

 To allow dynamic updates

Note

  • XOX


Checklist: Securing your DNS infrastructure

Step | Reference
To prevent anyone outside of your company from obtaining internal network information, use separate DNS servers for internal and Internet name resolution. Your internal DNS namespace should be hosted on DNS servers behind the firewall for your network. Your external, Internet DNS presence should be managed by a DNS server in a perimeter network (also known as DMZ, demilitarized zone, or screened subnet). To provide Internet name resolution for internal hosts, you can have your internal DNS servers use a forwarder to send external queries to your external DNS server. | Using forwarders; "Windows Server 2003 DNS" at the Microsoft Windows Resource Kits Web site (http://www.microsoft.com/)
To prevent anyone outside of your company from obtaining information about your internal DNS namespace, configure your external router and firewall to only allow DNS traffic between your internal and external DNS servers.

For the DNS servers in your network that are exposed to the Internet, restrict DNS zone transfers to either DNS servers identified in the zone by name server (NS) resource records or to specific DNS servers in your network.

Note

  • If you are using Microsoft Internet Security and Acceleration (ISA) Server, then you may use block filters to define the traffic allowed through the ISA Server.
 To modify DNS zone transfer settings; Microsoft Internet Security and Acceleration (ISA) Server Web site (http://www.microsoft.com/)
If the server running the DNS Server service is a multihomed computer, then restrict the DNS Server service to only listen on the interface IP address used by its DNS clients and internal servers. For example, a server acting as proxy server may have two network interface cards, one for the intranet and one for the Internet. If that server is also running the DNS Server service, you can configure the service to only listen for DNS traffic on the IP address used by the intranet network interface card. | To restrict a DNS server to listen only on selected addresses
If the server running DNS Server service is a domain controller, then use Active Directory access control lists (ACLs) to secure access control of the DNS Server service. | To modify security for the DNS Server service on a domain controller; Best practices for assigning permissions on Active Directory objects; Best practices for permissions and user rights; Understanding groups
Use Active Directory–integrated DNS zones. DNS zones stored in Active Directory can take advantage of Active Directory security features, such as secure dynamic update and the ability to apply Active Directory security settings to DNS servers, zones, and resource records. | To change the zone type; Active Directory integration; To allow only secure dynamic updates; To modify security for a directory-integrated zone; To modify security for a resource record
If a DNS zone is not stored in Active Directory, then secure the DNS zone file by modifying permissions on the DNS zone file or on the folder where the zone files are stored. The zone file or folder permissions should be configured to only allow Full Control to the System group. By default, zone files are stored in the systemroot\System32\Dns folder. | To set, view, change, or remove permissions on files and folders
Secure the DNS registry keys. The DNS registry keys can be found in the following registry location:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\

 To add users or groups to the Permissions list
Disable recursion on DNS servers that do not respond to DNS clients directly and are not configured with forwarders. A DNS server only requires recursion if it responds to recursive queries from DNS clients or is configured with a forwarder. DNS servers use iterative queries to communicate with each other. | To disable recursion on the DNS server
Secure the caches of all DNS servers against names pollution. | To secure server cache against names pollution
If you have a private internal DNS namespace, then configure the root hints on your internal DNS servers to only point to the DNS servers hosting your internal root domain and not the DNS servers hosting the Internet root domain. | To update root hints on the DNS server; Updating root hints


New ways to do familiar tasks

The following table lists common tasks for configuring Domain Name System (DNS). The user interface for performing these tasks is different in this version of Windows from the way it was in Microsoft® Windows® NT version 4.0.

Note

  • XOX
If you want to | In Windows NT 4.0 use | In this version of Windows use
Install a DNS server on this computer | Network in Control Panel | Windows Components wizard. | Open Windows Components wizard. For more information, see To install a DNS server.
Start DNS Manager | Start menu shortcut to DNS Manager, listed in Administrative Tools |  | Open the DNS console. For more information, see To open the DNS console.
Start or stop a DNS server | Services in Control Panel |  | Use the DNS console to start or stop a DNS server. For more information, see To start or stop a DNS server.
Add a remote server to DNS Manager. | Server menu in DNS Manager |  | Add the remote server to the DNS console. For more information, see To add a server to the DNS console.


Best practices

  • Enter the correct e-mail address of the responsible person for each zone you add to or manage on a DNS server.

    This field is used by applications to notify DNS administrators for a variety of reasons. For example, query errors, incorrect data returned in a query, and security problems are a few ways in which this field can be used. While most Internet e-mail addresses contain the at sign (@) when used in e-mail applications, this symbol must be replaced with a period (.) when entering an e-mail address for this field. For example, instead of "administrator@microsoft.com", you would use "administrator.microsoft.com".

    For more information on configuring the responsible person for a zone, see To modify the start of authority (SOA) record for a zone.

  • Be conservative in adding alias records to zones.

    Avoid using CNAME resource records (RRs) where they are not needed to alias a host name used in a host (A) resource record. Also, ensure that any alias names you use are not used in other RRs.

    DNS allows an owner name of a CNAME resource record to be used as the owner name of the other types of resource records, such as NS, MX, and TXT resource records.

    For more information, see Alias (CNAME) resource records.

  • When designing your DNS network use standard guidelines and, wherever possible, follow preferred practices for managing your DNS infrastructure.

    DNS was designed to provide a level of fault tolerance for resolving names. If possible, you should have at least two name servers hosting each zone.

  • If you are using Active Directory, use directory-integrated storage for your DNS zones for increased security, fault tolerance, simplified deployment and management.

    • By integrating zones, you can simplify network planning. For example, domain controllers for each of your Active Directory domains correspond in a direct one-to-one mapping to DNS servers. This can simplify planning and troubleshooting DNS and Active Directory replication problems because the same server computers are used in both topologies.

    If you are using directory-integrated storage for your zones, you may select from the different replication scopes that replicate your DNS zone data throughout the directory. If your DNS infrastructure must support Windows 2000 DNS servers, you will use the directory-integrated storage method that replicates DNS zone data to all domain controllers in a domain. If your DNS infrastructure is composed of DNS servers running Windows Server 2003 only, you may also select from replication scopes that replicate your DNS zone data to all DNS servers in the Active Directory forest, all DNS servers in a specified Active Directory domain, or all domain controllers specified in a custom replication scope.

    For more information on directory-integrated DNS zone storage and replication options, see DNS zone replication in Active Directory.

    Any DNS server hosting a directory-integrated zone is a primary DNS server for that zone. This enables a multimaster model where multiple DNS servers may update the same zone data. A multimaster model eliminates a single point of failure associated with a conventional single-master DNS topology, where updates may only be done to a single DNS server for a given zone.

    One of the important benefits of directory integration is the support for secure dynamic update of the names within a zone. For more information, see Secure dynamic updates.

  • Consider the use of secondary zones to assist in off-loading DNS query traffic wherever it makes sense.

    Secondary servers can be used as backups for DNS clients. This allows you to use secondary servers as a means to load balance DNS query traffic on your network and reserve your DNS-enabled primary servers for use only by those clients that need them to perform dynamic registration and updates of their A and PTR RRs.

    For more information about the use of secondary or caching-only servers, see Using secondary servers and Using caching-only servers.

  • If you are planning a large DNS design, such as for a large Internet service provider (ISP) that supports the use of DNS, review the following Request for Comments (RFC) documents published by the Internet Engineering Task Force (IETF).
    • RFC | Title
1912 | Common DNS Operational and Configuration Errors
2182 | Selection and Operation of Secondary DNS Servers
2219 | Use of DNS Aliases for Network Services

    You can obtain these RFCs from the RFC Editor Web site. This Web site is currently maintained by members of the Information Sciences Institute (ISI) who publish a classified listing of all RFCs. RFCs are classified as one of the following: approved Internet standards, proposed Internet standards (circulated in draft form for review), Internet best practices, or For Your Information (FYI) documents.

    To see the most current RFCs related to actively defining the DNS standard, see DNS Extension (dsnext) at the Internet Engineering Task Force Web site, which discusses dynamic update, notify, zone transfers, security, and adjustments to address the requirements of IPv6 addressing. Also, see DNS operations (dnsop) at the Internet Engineering Task Force Web site, which provides guidelines for the implementation of DNS by administrators of DNS domains.

Note

  • XOX


How to...

  • Install and configure servers
  • Install and configure clients
  • Manage servers
  • Optimize servers
  • Monitor servers
  • Add and remove zones
  • Configure zone properties
  • Manage zones
  • Manage resource records
  • Use aging and scavenging


Install and configure servers

  • Install a DNS server
  • Configure a DNS server for use with Active Directory
  • Verify DNS registration for domain controllers using the nslookup command
  • Configure a new DNS server
  • Modify security for the DNS Server service on a domain controller
  • Add a secondary server for an existing zone
  • Install a caching-only DNS server
  • Restrict a DNS server to listen only on selected addresses
  • Configure a DNS server to use conditional forwarders
  • Create the default DNS application directory partitions
  • Create a DNS application directory partition
  • Enlist a DNS server in a DNS application directory partition
  • Remove a DNS server from a DNS application directory partition


Install a DNS server

Microsoft Windows graphic

To install a DNS server

  1. Open Windows Components Wizard.
  2. In Components, select the Networking Services check box, and then click Details.
  3. In Subcomponents of Networking Services, select the Domain Name System (DNS) check box, click OK, and then click Next.
  4. If prompted, in Copy files from, type the full path to the distribution files, and then click OK.

    Required files are copied to your hard disk.

Notes

  • XOX
  • XOX
  • XOX
  • It is recommended that you manually configure the computer to use a static IP address. If the DNS server is configured to use DHCP-assigned dynamic addresses, when the DHCP server assigns a new IP address to the DNS server, the DNS clients configured to use that DNS server's previous IP address will be unable to resolve the previous IP address and locate the DNS server.
  • After you install a DNS server, you can decide how to administer it and its zones. Although you can use a text editor to make changes to server boot and zone files, this method is not recommended. The DNS console and the DNS command-line tool, dnscmd, simplify maintenance of these files and should be used whenever possible. Once you begin using console-based or command-line management of these files, manually editing them is not recommended. For more information, see Related Topics.
  • DNS zones stored in Active Directory can be administered using the DNS console or the dnscmd command-line tool only. These zones cannot be administered using a text editor.
  • If you uninstall a DNS server hosting Active Directory–integrated zones, these zones will be saved or deleted according to their storage type. For all storage types, the zone data is stored on other domain controllers or DNS servers and will not be deleted unless the DNS server that you uninstall in the last DNS server hosting that zone.
  • If you uninstall a DNS server hosting standard DNS zones, the zone files will remain in the systemroot\system32\Dns directory, but they will not be reloaded if the DNS server is reinstalled. If you create a new zone with the same name as an old zone, the old zone file is replaced with the new zone file.
  • When writing DNS server boot and zone data to text files, DNS servers use the Berkeley Internet Name Domain (BIND) file format recognized by legacy BIND 4 servers, not the more recent BIND 8 format.

Related Topics


Configure a DNS server for use with Active Directory

Microsoft Windows graphic

To configure a DNS server for use with Active Directory

  • When Active Directory is installed using the Active Directory Installation Wizard, the option to automatically install and configure a local DNS server for use is provided.

    To install Active Directory on this computer, use the Active Directory Installation Wizard. For more information, see Related Topics.

Notes

  • XOX
  • This procedure only applies to server computers used as domain controllers. If member servers are used as DNS servers, they are not integrated with Active Directory.
  • If you choose the Active Directory Installation Wizard option to automatically install and configure a local DNS server, the DNS server is installed on the computer where you are running the wizard and the computer's preferred DNS server setting is configured to use the new local DNS server. You will also want to configure any other computers that will join this domain to use this DNS server's IP address as their preferred DNS server.
  • For more information about setting up DNS for Active Directory, see Microsoft Windows Deployment and Resource Kits.
  • XOX

Related Topics


Verify DNS registration for domain controllers using the nslookup command

Microsoft Windows graphic

To verify DNS registration for domain controllers using the nslookup command

  1. Open Command Prompt.
  2. Type:

    nslookup

  3. After the previous command completes, at the nslookup (">") prompt type:

    4. set q=rr_type

  4. After the previous command completes, type:

    5. _ldap._tcp.dc._msdcs.Active_Directory_domain_name

  5. Review the output of the previous SRV query and determine if further action is needed based on whether the previous query succeeded or failed:
    • If the query succeeded, review the registered SRV RRs returned in the query to determine if all domain controllers for your Active Directory domain are included and registered using valid IP addresses.
    • If the query failed, continue troubleshooting dynamic update or DNS server related issues to determine the exact cause of the problem.
Value | Description
nslookup | The name of the command-line program.
_ldap._tcp.dc._msdcs.Active_Directory_domain_name | The DNS name configured for use with your Active Directory domain and any of its associated domain controllers. For example, if the DNS domain name of your Active Directory domain is example.microsoft.com, type: _ldap._tcp.dc._msdcs.example.microsoft.com.
set q= | The command to send the query to the root server.
rr_type | The resource record (RR) type to apply as a filter for subsequent lookups. For example, in this instance, because you want to limit subsequent name queries to filter and return only service location (SRV) RRs that use a specified name, type: set q=srv

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    nslookup, press Enter and then type help

  • In some cases, when performing the above procedure, you might see several time-outs reported. This happens when reverse lookup is not configured for DNS servers servicing the same DNS domain as your Active Directory domain.
  • The following is an example of command-line output for an Nslookup session, used to verify service location (SRV) resource records that are registered by domain controllers. In this example, the two domain controllers are dc1 and dc2 and are registered for the "example.microsoft.com" domain.

C:\nslookup
Default Server:  dc1.example.microsoft.com
Address:  10.0.0.14
 set type=srv
 _ldap._tcp.dc._msdcs.example.microsoft.com
Server:  dc1.example.microsoft.com
Address:  10.0.0.14
_ldap._tcp.dc._msdcs.example.microsoft.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = dc1.example.microsoft.com
_ldap._tcp.dc._msdcs.example.microsoft.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = dc2.example.microsoft.com
dc1.example.microsoft.com     internet address = 10.0.0.14
dc2.example.microsoft.com     internet address = 10.0.0.15
  • The nslookup command is a standard command-line tool provided in most DNS service implementations. It offers the ability to perform query testing of DNS servers and obtain detailed responses as the command output. This information is useful in troubleshooting name resolution problems, verifying that resource records (RRs) are added or updated correctly in a zone, and debugging other server-related problems.
  • Verify that resource records used to register services and critical hosts, such as domain controllers, are correctly added to zones.

    In some cases, you might need to manually add or verify registration of the service location (SRV) resource records used to support Windows Server 2003 domain controllers.

    To add the SRV resource records that have been created for a domain controller, open and view the Netlogon.dns file, created by the Active Directory Installation wizard when a server computer is promoted to a domain controller. It can be found at:

    systemroot\System32\Config\Netlogon.dns

  • The resource records used in this file are listed in RFC-compliant text-file format. When verifying these records, look for the following records:

    _ldap._tcp.Active_Directory_domain_name IN SRV 0 0 389 ldap_server_name
    _ldap._tcp.dc._msdcs.Active_Directory_domain_name IN SRV 0 0 389 domain_controller_name

    In some cases, you might need to modify the Lightweight Directory Access Protocol (LDAP) server name if you are using a non-domain controller as an LDAP server for your network.

  • The Net Logon service on each domain controller registers, as appropriate, a number of different DNS resource records with DNS servers. To learn more about these records and how Net Logon updates DNS, obtain additional technical information on DNS available from the Microsoft Web site. For more information, see Related Topics.

Related Topics


Configure a new DNS server

Microsoft Windows graphic

To configure a new DNS server

Using the Windows interface

  1. Open DNS.
  2. If needed, add and connect to the applicable server in the console.
  3. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • Applicable DNS server
  4. On the Action menu, click Configure a DNS Server.
  5. Follow the instructions in the Configure a DNS Server Wizard.

Notes

  • XOX
  • XOX
  • If the DNS server is running locally, you do not need to perform step 2.
  • As a best practice, use the checklist for installing a new DNS server. For more information, see Related Topics.
  • When you finish configuring the server, you might need to complete additional tasks, such as enabling dynamic updates for its zones or adding resource records to its zones.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /Config {ZoneName|..AllZones} Property {1|0}

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/Config | Specifies the configuration command.
{ZoneName|..AllZones} | Specifies the name of the zone to be configured. To apply the configuration for all zones hosted by the specified DNS server, type ..AllZones.
Property | Specifies the server property or zone property to be configured. There are different properties available for servers and zones. For a list of the available properties, at the command prompt, type: dnscmd /Config /help.
{1|0} | Sets configuration options to either 1 (on) or 0 (off). Note that some server and zone properties must be reset as part of a more complex operation.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /Config /help

  • As a best practice, use the checklist for installing a new DNS server provided in the online Help. For more information, see Related Topics.
  • When you finish configuring the server, you might need to complete additional tasks, such as enabling dynamic updates for its zones or adding resource records to its zones.
XOX

Related Topics


Modify security for the DNS Server service on a domain controller

Microsoft Windows Graphic

To modify security for the DNS Server service on a domain controller

  1. Open DNS.
  2. In the console tree, right-click the applicable server, and then click Properties.
  3. On the Security tab, modify the list of member users or groups that are allowed to administer the applicable server.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Active Directory access control lists (ACLs) are only supported for the DNS Server service when it is running on a domain controller.
  • The security settings determine who can administer the server, but do not affect the ACLs for the zones and resource records hosted on the server. To apply security settings for DNS zones and resource records, see Related Topics.
  • XOX

Related Topics


Add a secondary server for an existing zone

Microsoft Windows graphic

To add a secondary server for an existing zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • Applicable DNS server
  3. On the Action menu, click New Zone.
  4. Follow the instructions in the New Zone Wizard.

    When adding the zone, select Secondary zone as the zone type.

Notes

  • XOX
  • XOX
  • If the DNS server is running locally, you do not need to perform step 2.
  • In order to add a secondary server for an existing zone, you need to have network access to the server acting as the master server for this server and its use of the zone. The master server acts as the source for zone data. It is contacted periodically to assist in renewing the zone and to transfer zone updates whenever they are needed.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneAdd ZoneName /Secondary MasterIPaddress... [/file FileName]

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/ZoneAdd | Required. Adds a zone.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the secondary zone you are adding. The zone name must be the same as the primary zone from which the secondary zone is created.
/Secondary | Required. Adds a secondary zone type.
MasterIPaddress... | Required. Specifies one or more IP addresses for the master servers of the secondary zone, from which it copies zone data.
/file | Specifies the command to use a file.
FileName | Specifies the name of the file to use for creating the secondary zone.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneAdd /help

  • To add a secondary server for an existing zone, you need to have network access to the server acting as the master server for this server and its use of the zone. The master server acts as the source for zone data. It is contacted periodically to assist in renewing the zone and to transfer zone updates whenever they are needed.
XOX

Related Topics


Install a caching-only DNS server

Microsoft Windows graphic

To install a caching-only DNS server

  1. To install a caching-only DNS server, install a DNS server on the server computer.
  2. Do not configure the DNS server (as you might normally) to load any zones.
  3. Verify server root hints are configured or updated correctly.

    For more information, see Related Topics.

Notes

  • XOX
  • Caching-only DNS servers do not host any zones and are not authoritative for a particular domain. They are DNS servers that build a local server cache of names learned while performing recursive queries on behalf of their clients. This information is then available from its cache when answering subsequent client queries.
  • A caching-only DNS server can be valuable at a site where DNS functionality is needed locally but it is not administratively desirable to create a separate domain or zone for that location.
  • It is strongly recommended that, when operating the computer as a DNS server, you manually configure TCP/IP and use a static IP address.

Related Topics


Restrict a DNS server to listen only on selected addresses

Microsoft Windows graphic

To restrict a DNS server to listen only on selected addresses

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. On the Interfaces tab, click Only the following IP addresses.
  5. In IP address, type an IP address for the DNS server to be enabled for use, and then click Add.
  6. As needed, repeat the previous step to specify other server IP addresses to be enabled for use by this DNS server.

    If you need to remove an IP address from the list, click it and then click Remove.

Notes

  • XOX
  • XOX
  • By default, the DNS Server service listens for DNS message communications on all configured IP addresses for the server computer.
  • Server IP addresses that are added here need to be statically managed. If later you change or remove addresses specified here from TCP/IP configurations maintained at this server, update this list accordingly.
  • After you update or revise the list of restricted interfaces, you need to stop and restart the DNS server to apply the new list.
  • Restricting the DNS Server service to only listen on specific IP addresses is an effective security measure because only hosts on the same network subnet, or hosts with a router that connects them to that same segment, will have access to the server.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ResetListenAddresses [ListenAddress ...]

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/ResetListenAddresses | Required. Resets the IP addresses of the interfaces on which the DNS server listens.
ListenAddress... | Specifies one or more IP addresses for the interfaces on which you want the DNS server to listen. By default, the DNS Server service listens for DNS message communications on all configured IP addresses for the server computer.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd ServerName /ResetListenAddresses /help

  • Server IP addresses that are added here need to be statically managed. If later you change or remove addresses specified here from TCP/IP configurations maintained at this server, update this list accordingly.
  • After you update or revise the list of restricted interfaces, you need to stop and restart the DNS server to apply the new list.
  • Restricting the DNS Server service to only listen on specific IP addresses is an effective security measure because only hosts on the same network subnet, or hosts with a router that connects them to that same segment, will have access to the server.
XOX
Related Topics


Configure a DNS server to use forwarders

Microsoft Windows graphic

To configure a DNS server to use forwarders

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. On the Forwarders tab, under DNS domain, click a domain name.
  5. Under Selected domain's forwarder IP address list, type the IP address of a forwarder, and then click Add.

Notes

  • XOX
  • XOX
  • To create a new domain name, click New, and then under DNS domain, type the domain name.
  • When specifying a conditional forwarder, select a DNS domain name before entering an IP address.
  • By default, the DNS server will wait 5 seconds for a response from one forwarder IP address before trying another forwarder IP address. In Number of seconds before forward queries time out, you can change the number of seconds the DNS server will wait. When the server has exhausted all forwarders, it will attempt standard recursion.
  • If you want the DNS server to only use forwarders and not attempt any further recursion if the forwarders fail, select the Do not use recursion for this domain check box.

    You can disable recursion for the DNS server so that it will not perform recursion on any query. If you disable recursion on the DNS server, you will not be able to use forwarders on the same server. For more information about disabling recursion on the DNS server, see Related Topics.

  • Do not enter a forwarder's IP address more than once in a DNS server's forwarders list because it is a more reliable or geographically closer server. If one of the forwarders is preferred, that forwarder should be ordered first in the series of forwarder IP addresses.
  • You cannot use a domain name in a conditional forwarder if the DNS server hosts a primary, secondary, or stub zone for that domain name. For example, if a DNS server is authoritative for the domain name example.microsoft.com (hosts the primary zone for that domain name), then you cannot configure that DNS server with a conditional forwarder for example.microsoft.com.
  • Problems associated with forwarders often result from inefficient configurations and overuse. For information on some common problems, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneAdd ZoneName /Forwarder MasterIPaddress … [/TimeOut Time] [/Slave]

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/ZoneAdd | Required. Adds a zone.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
/Forwarder | Required. Specifies the command to configure a forwarder. When configuring forwarders on DNS servers running on Active Directory domain controllers, you must use /DsForwarder in place of /Forwarder. /DsForwarder will replicate the forwarder setting to all DNS servers running on domain controllers in an Active Directory domain.
MasterIPaddress... | Required. Specifies a space-separated list of one or more IP addresses of the DNS servers where queries for ZoneName are forwarded. You may specify a list of space-separated IP addresses.
/TimeOut | Specifies the timeout setting. The timeout setting is the number of seconds before unsuccessful forward queries time out.
Time | Specifies the value for the /TimeOut parameter. The value is in seconds. The default timeout is 5 seconds.
/Slave | Determines whether or not the DNS server uses recursion when querying for the domain name specified by ZoneName.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneAdd /help

  • To view a zone added for use as only a conditional forwarder, use the following command:

    dnscmd ServerName /ZoneInfo ZoneName

  • To reset the forwarder IP addresses for a conditional forwarder domain name, type:

    dnscmd ServerName /ZoneResetMasters ZoneName [/Local] [ServerIPs]

    The /Local parameter sets the local master list for Active Directory–integrated forwarders and the ServerIPs parameter is the list of one or more IP addresses of master servers for the zone. Master servers may include DNS servers that host primary or secondary copies of the zone, but should not include DNS server IP addresses in such a way that two DNS servers hosting copies of a zone use each other as master servers. Such a configuration would make the forwardering path cyclical.

  • To reset the standard, non-conditional forwarder for a DNS server, type:

    dnscmd ServerName /ResetForwarders [IPAddress …] [ /[No]Slave ] [/TimeOut Time]

    The parameter IPAddress is the IP address where the DNS server will forward unsolvable DNS queries. The /Slave parameter sets the DNS server as a subordinate server. The /NoSlave parameter (default setting) sets the DNS server as a non-subordinate server, meaning that it will perform recursion. The /Timeout and Time parameters are described in the table above.

  • You cannot use a domain name in a conditional forwarder if the DNS server hosts a primary, secondary, or stub zone for that domain name. For example, if a DNS server is authoritative for the domain name example.microsoft.com (hosts the primary zone for that domain name), then you cannot configure that DNS server with a conditional forwarder for example.microsoft.com.
  • Problems associated with forwarders often result from inefficient configurations and overuse. For information on some common problems, see Related Topics.
XOX

Related Topics


Create the default DNS application directory partitions

Microsoft Windows Graphic

To create the default DNS application directory partitions

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. Click Create Default Application Directory Partitions.
  4. Follow the instructions to create the DNS application directory partitions.

Notes

  • By default, only members of the Enterprise Admins group can create a DNS application directory partition.
  • XOX
  • By default, the DNS Server service will attempt to locate and create the default DNS application directory partitions in Active Directory. If the DNS Server service is unable to do this, the administrator can manually create the application directory partitions using this procedure.
  • If the default DNS application directory partitions are currently available in Active Directory, the option to create the default application directory partitions in the DNS console will not be available.
  • The following table describes the options available when creating the DNS default application directory partitions.
    Option | Partition name | Description
    Create a single application directory partition that stores DNS zone data and replicates that data to all DNS servers in the domain | DomainDnsZones.DnsDomainName | DNS application directory partition for each domain in the forest. DNS zones stored in this application directory partition are replicated to all DNS servers running on domain controllers in the domain.
    Create a single application directory partition that stores DNS zone data and replicates that data to all DNS servers in the forest | ForestDnsZones.DnsForestName | DNS application directory partition for the entire forest. It contains all the DNS servers running on the domain controllers in the forest. DNS zones stored in this application directory partition are replicated to all DNS servers running on domain controllers in the forest.
  • By default, the Net Logon service registers domain controller locator (Locator) DNS resource records for any application directory partitions hosted on a domain controller in the same manner as it registers domain controller locator (Locator) DNS resource records for any domain hosted on a domain controller. Once the default DNS application directory partitions are created, Net Logon will register domain controller locator (Locator) DNS resource records on behalf of the domain controller hosting the default DNS application directory partitions.
  • For more information about creating and deleting an application directory partition, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /CreateBuiltinDirectoryPartitions {/Domain|/Forest|/AllDomains}

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/CreateBuiltinDirectoryPartitions | Required. Creates a default application directory partition.
{/Domain|/Forest|/AllDomains} Required. Specifies which default application directory partition to create. Do one of the following:
  • To create a default domain-wide DNS application directory partition for the Active Directory domain where the specified DNS server is located, type /Domain.
  • To create a default forest-wide DNS application directory partition for the Active Directory forest where the specified DNS server is located, type /Forest.
  • To create a default domain-wide DNS application directory partitions on a DNS server in each domain in the Active Directory forest where the user running this command is logged on, type /AllDomains.
The ServerName parameter is ignored for /AllDomains. The computer on which this command is run must be joined to a domain in the forest where you want to create all of the default domain-wide application directory partitions.

Notes

  • By default, only members of the Enterprise Admins group can create a DNS application directory partition.
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /CreateDirectoryPartition /?

  • By default, the DNS Server service will attempt to locate and create the default DNS application directory partitions in Active Directory. If the DNS Server service is unable to do this, the administrator can manually create the application directory partitions using this procedure.
  • If the default DNS application directory partitions are currently available in Active Directory, the option to create a default application directory partition in the DNS console will not be available.
  • The following table describes the options available when creating the DNS default application directory partitions.
    Option | Partition name | Description
    Create a single application directory partition that stores DNS zone data and replicates that data to all DNS servers in the domain | DomainDnsZones.DnsDomainName | DNS application directory partition for each domain in the forest. DNS zones stored in this application directory partition are replicated to all DNS servers running on domain controllers in the domain.
    Create a single application directory partition that stores DNS zone data and replicates that data to all DNS servers in the forest | ForestDnsZones.DnsForestName | DNS application directory partition for the entire forest. It contains all the DNS servers running on the domain controllers in the forest. DNS zones stored in this application directory partition are replicated to all DNS servers running on domain controllers in the forest.
  • By default, the Net Logon service registers domain controller locator (Locator) DNS resource records for any application directory partitions hosted on a domain controller in the same manner as it registers domain controller locator (Locator) DNS resource records for any domain hosted on a domain controller. Once the default DNS application directory partitions are created, Net Logon will register domain controller locator (Locator) DNS resource records on behalf of the domain controller hosting the default DNS application directory partitions.
  • For more information about creating and deleting an application directory partition, see Related Topics.
XOX

Related Topics


Create a DNS application directory partition

Microsoft Windows Graphic

To create a DNS application directory partition

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /CreateDirectoryPartition FQDN

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/CreateDirectoryPartition | Required. Creates a DNS application directory partition.
FQDN | Required. Specifies the name of the new DNS application directory partition. You must use a DNS fully qualified domain name (FQDN).

Notes

  • By default, only members of the Enterprise Admins group can create a DNS application directory partition.
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /CreateDirectoryPartition /?

XOX

Related Topics


Enlist a DNS server in a DNS application directory partition

Microsoft Windows Graphic

To enlist a DNS server in a DNS application directory partition

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /EnlistDirectoryPartition FQDN

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/EnlistDirectoryPartition | Required. Enlists a DNS server in a DNS application directory partition.
FQDN | Required. Specifies the fully qualified domain name (FQDN) of the DNS application directory partition.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /EnlistDirectoryPartition /?

  • For more information about creating and deleting an application directory partition, see Related Topics.
XOX

Related Topics


Remove a DNS server from a DNS application directory partition

Microsoft Windows Graphic

To remove a DNS server from a DNS application directory partition

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /UnenlistDirectoryPartition FQDN

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/UnenlistDirectoryPartition | Required. Removes a DNS server from a DNS application directory partition.
FQDN | Required. Specifies the fully qualified domain name (FQDN) of the DNS application directory partition from which you are removing the DNS server specified by ServerName.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /UnenlistDirectoryPartition /?

  • For more information about creating and deleting an application directory partition, see Related Topics.
XOX

Related Topics


Install and configure clients

  • Configure DNS for static clients
  • Enable DNS for DHCP-enabled clients
  • Configure the primary DNS suffix for a client computer
  • Preload the client resolver cache
  • Display and view a client resolver cache using the ipconfig command
  • Flush and reset a client resolver cache using the ipconfig command
  • Renew DNS client registration using the ipconfig command


Configure DNS for static clients

Microsoft Windows graphic

To configure DNS for static clients

  • To configure DNS for clients with statically configured IP addresses, you likely need to configure the following:
    1. DNS host name (or names) for the client computer.
    2. Primary and alternate DNS servers that the client uses to assist in resolving DNS domain names.
    3. A list of DNS suffixes to be appended for use in completing unqualified DNS names, which are used for searching and submitting DNS queries at the client for resolution.
    4. Connection-specific dynamic update and registration behavior, such as whether specific network adapters installed at the client dynamically register their configured IP addresses with a DNS server.

Notes

  • XOX
  • For more information about how to configure DNS for static clients not running XOX, see the applicable TCP/IP or DNS documentation provided by the appropriate vendor for these clients.
  • By default, the DNS client on XOX does not attempt dynamic update over a Remote Access Service (RAS) or virtual private network connection. To modify this configuration, you can modify the advanced TCP/IP settings of the particular network connection or modify the registry. For more information, see Related Topics.
  • By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone named with a single-label name is considered a TLD zone, for example, com, edu, blank, my-company. To configure the DNS client to allow the dynamic update of TLD zones, you can use the Update Top Level Domain Zones policy setting or modify the registry.

Related Topics


Enable DNS for DHCP-enabled clients

Microsoft Windows graphic

To enable DNS for DHCP-enabled clients

  • To configure DNS for clients with dynamically configured IP addresses provided by a DHCP server, you generally need to configure the following at either the DHCP server or applicable clients:
    1. DNS host name (or names) for the client computer.

      For DHCP clients, this must be set at the client computer or assigned during unattended setup.

    2. Primary and alternate DNS servers that the client uses to assist in resolving DNS domain names.

      For DHCP clients, this can be set by assigning the DNS server option (option 6) and providing a configured list of ordered IP addresses for the DNS servers that the client is configured to use.

    3. A list of DNS suffixes to be appended for use in completing unqualified DNS names used for searching and submitting DNS queries at the client for resolution.

      For DHCP clients, this can be set by assigning the DNS domain name option (option 15) and providing single DNS suffix for the client to append and use in searches. To configure additional DNS suffixes, configure TCP/IP manually for DNS configuration.

    4. Connection-specific dynamic update and registration behavior, such as whether specific network adapters installed at the client dynamically register their configured IP addresses with a DNS server.

      For DHCP clients, the default is for client connections to register their configured IP addresses with a DNS server. To modify this behavior at the client, configure TCP/IP manually for DNS configuration.

Notes

  • XOX
  • For more information on how to configure other DNS for DHCP clients, see the applicable TCP/IP or DNS documentation provided by the appropriate vendor.
  • By default, the DNS client on XOX does not attempt dynamic update over a Remote Access Service (RAS) or virtual private network connection. To modify this configuration, you can modify the advanced TCP/IP settings of the particular network connection or modify the registry. For more information, see Related Topics.
  • By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone named with a single-label name is considered a TLD zone, for example, com, edu, blank, my-company. To configure the DNS client to allow the dynamic update of TLD zones, you can use the Update Top Level Domain Zones policy setting or modify the registry.
  • For more information about DHCP options, see "DHCP Options" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Related Topics


Configure the primary DNS suffix for a client computer

Microsoft Windows graphic

To configure the primary DNS suffix for a client computer

  1. Open System in Control Panel.
  2. Click the Computer Name tab.

    This tab displays the computer name, the workgroup or domain to which it belongs, and a brief description of the computer.

  3. Click Change, and then click More.
  4. In DNS Suffix and NetBIOS Computer Name, do the following:

    For Primary DNS suffix of this computer, specify the DNS suffix to be appended to the name of this computer when completing its fully qualified domain name (FQDN).

  5. After applying these changes, restart the computer to initialize it with its new DNS domain name.
  6. If the computer has been previously installed and configured as a DNS server, verify that zone authority records are updated.

    These include the start of authority (SOA) and name server (NS) resource records, substituting the new FQDN to replace the single label name previously in use. For more information, see Related Topics.

Notes

  • XOX
  • To open System, click Start, point to Settings, and then click Control Panel. In Control Panel, double-click System.
  • For more information about how to configure the primary DNS suffix for other clients and servers, see the applicable TCP/IP or DNS documentation provided by the appropriate vendor for your other clients.
  • By default, the primary DNS suffix portion of a computer's FQDN is the same as the name of the Active Directory domain to which the computer is joined. To allow different primary DNS suffixes, a domain administrator can create a restricted list of allowed suffixes by modifying the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is managed by the domain administrator using Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP).

Related Topics


Preload the client resolver cache

Microsoft Windows graphic

To preload the client resolver cache

  1. At the client computer, open Command Prompt.
  2. At the command prompt, type the following command:

    3. notepad %systemroot%\system32\drivers\etc\hosts

  3. Using the default entry in the file (a mapping for the local host to the loopback IP address, 127.0.0.1), add additional host name-to-address mappings on separate lines to be preloaded into the resolver cache of the client. For example, you might add:

    10.0.0.1 host-a host-a.example.microsoft.com

  4. On the File menu, click Save, and then Exit.
  5. As an option, you can verify that your changes have been updated in the resolver cache by viewing its contents.

Notes

  • XOX
  • XOX
  • XOX
  • Entries you add are always answered first from the local resolver cache and not sent to the DNS query when queries are made locally to resolve these names to host (A) resource records.
  • Every line in the Hosts file should contain an IP address followed by one or more host names. For example, you could add a line such as the following with an IP address (10.0.0.1) that maps to more than one DNS host name:

    10.0.0.1 host-a host-a.example.microsoft.com host-b.example2.microsoft.com

    Likewise, a single DNS host name can correspond to more than one IP address if each of the addresses is mapped and used in separate lines. For example, you could add lines for the following multi-homed or multi-addressable DNS host computer:

    10.0.0.1 host-a.example.microsoft.com
    10.0.0.2 host-a.example.microsoft.com
    10.0.0.3 host-a.example.microsoft.com

  • When multiple names or IP addresses are used in the file, the DNS Client service must be running for all entries to be returned or used in answering queries. If the DNS Client service is not running, only the first entry in the file is used to resolve the query.

Related Topics


Display and view a client resolver cache using the ipconfig command

Microsoft Windows graphic

To display and view a client resolver cache using the ipconfig command

  1. Open Command Prompt.
  2. Type:

    ipconfig /displaydns

Value | Description
ipconfig | The name of the command-line program.
/displaydns | The command to display a client resolver cache.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    ipconfig /help

  • To pause the display of the command output to one screen at time, type ipconfig /displaydns|more.
  • The ipconfig /displaydns command provides you with a means to view the contents of the DNS client resolver cache, which includes entries preloaded from the local Hosts file, as well as any recently obtained resource records for name queries resolved by the system. This information is used by the DNS Client service to quickly resolve frequently queried names before it queries its configured DNS servers.
  • When the ipconfig /displaydns command is used to display current resolver cache contents, the resultant output generally includes the local host and loopback IP address (127.0.0.1) mappings. This is because these mappings typically exist in the default (unmodified) contents of the local Hosts file.
  • After you can add host mapping entries to the local Hosts file and save the file, these entries are added to the displayed output of this command. For more information, see Related Topics.
  • The resolver cache can also support negative caching of unresolved or non-valid DNS names. These entries are added by the DNS Client service when it receives a negative answer from a DNS server for a queried name. The negative result is cached for a short period of time so that it is not again queried, which could cause query performance problems.

    During DNS troubleshooting, you can flush and reset the cache to discard negative entries from the cache and any other dynamically added entries that were not preloaded. For more information, see Related Topics.

  • Although the ipconfig command is provided for earlier versions of Windows, the /displaydns option is only available for use on computers running Windows 2000, XOX, or Windows Server 2003 operating systems.

Related Topics


Flush and reset a client resolver cache using the ipconfig command

Microsoft Windows graphic

To flush and reset a client resolver cache using the ipconfig command

  1. Open Command Prompt.
  2. Type:

    ipconfig /flushdns

Value | Description
ipconfig | The name of the command-line program.
/flushdns | The command to flush and reset a client resolver cache.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    ipconfig /help

  • The ipconfig /flushdns command provides you with a means to flush and reset the contents of the DNS client resolver cache. During DNS troubleshooting, if necessary, you can use this procedure to discard negative cache entries from the cache, as well as, any other dynamically added entries.
  • Resetting the cache does not eliminate entries that are preloaded from the local Hosts file. To eliminate those entries from the cache, remove them from this file. For more information, see Related Topics.
  • Although the ipconfig command is provided for earlier versions of Windows, the /flushdns option is only available for use on computers running Windows 2000, XOX, or Windows Server 2003 operating systems.

Related Topics


Renew DNS client registration using the ipconfig command

Microsoft Windows graphic

To renew DNS client registration using the ipconfig command

  1. Open Command Prompt.
  2. Type:

    ipconfig /registerdns

Value | Description
ipconfig | The name of the command-line program.
/registerdns | The command to renew DNS client registration.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    ipconfig /help

  • An additional command to /registerdns is to type:

    ipconfig /registerdns [adapter]

    Where adapter is the name of a specific network adapter installed on the computer for which you want to renew or update registrations.

  • The ipconfig /registerdns command provides you with a means to manually initiate dynamic registration for the DNS names and IP addresses configured at a computer. This option can assist in troubleshooting a failed DNS name registration or in resolving a dynamic update problem between a client and the DNS server without restarting the client.
  • By default, the ipconfig /registerdns command refreshes all DHCP address leases and registers all related DNS names configured and used by the client computer.
  • To learn the names of adapters that you can optionally specify with this command, first type the ipconfig command by itself (that is, do not specify any additional parameters). The command output displays all adapters by name that are available for use at the computer.
  • Although the ipconfig command is provided for earlier versions of Windows, the /registerdns option is only available for use on computers running Windows 2000, XOX, or Windows Server 2003 operating systems.
  • On computers running Windows 2000, XOX, or Windows Server 2003 operating systems, the DHCP Client service is used to perform dynamic registrations and updates, regardless of whether the computer uses a DHCP server or static configuration to obtain its IP address.
  • If you are troubleshooting a failed DNS dynamic registration for a client computer and its DNS names, it might help to verify that the cause is not related to one of the following commonly known causes for such failures:
    1. The zone where the client requires update or registration is not able to accept dynamic updates.
    2. The DNS servers that the client is configured to use do not support or recognize the DNS dynamic update protocol.
    3. The primary (or directory-integrated) DNS server for the zone refused the update request. This can most likely occur because the client is not permitted under current zone or resource records security sufficient access rights to update its own name.
    4. The server or zone is not available because of other problems, such as a network or server failure.

Related Topics


Manage servers

  • Open the DNS console
  • Start or stop a DNS server
  • Add a server to the DNS console
  • Remove a server from the DNS console
  • Manually update server data files
  • Change the boot method used by the DNS server
  • Change the name-checking method used by the DNS server
  • Restrict NS resource record registration
  • Allow NS record creation for specific domain controllers
  • Restrict DNS resource records updated by Net Logon


Open the DNS console

Microsoft Windows graphic

To open the DNS console

  • Open DNS.

Notes

  • XOX
  • XOX
  • The DNS console is an administrative tool for managing DNS servers running Windows Server 2003 family operating systems only. For more information, see Related Topics.

Related Topics


Start or stop a DNS server

Microsoft Windows graphic

To start or stop a DNS server

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • Applicable DNS server
  3. On the Action menu, point to All Tasks and then click one of the following:
    • To start the service, click Start.
    • To stop the service, click Stop.
    • To interrupt the service, click Pause.
    • To stop and then automatically restart the service, click Restart.

Notes

  • XOX
  • XOX
  • After you pause or stop the service, on the Action menu, in All Tasks, you can click Resume to immediately resume service.
  • When using registry-based configuration, changes are applied to DNS servers only when the DNS Server service is re-initialized. In these cases, if a DNS value is manually changed directly in the registry, the DNS Server service must always be restarted for the new value to be used.

Related Topics


Add a server to the DNS console

Microsoft Windows graphic

To add a server to the DNS console

  1. Open DNS.
  2. On the Action menu, click Connect To DNS Server.
  3. In Connect to DNS Server, click either:
    • This computer, if the server you want to connect to and manage is located on the same computer you are using to manage it.
    • The following computer, if the server you want to connect to and manage is located on a remote computer.

    If you choose to connect to a remote server, specify either its DNS computer name or its IP address.

  4. Select the Connect to the specified computer now check box, and then click OK.

Notes

  • XOX
  • XOX
  • The DNS console is a Microsoft Management Console (MMC) administrative tool for managing DNS servers running Windows Server 2003 operating systems only. For more information, see Related Topics.
  • If you use the Windows Server 2003 DNS console to administer a Windows 2000 DNS server, any new features will not be available when viewing the Windows 2000 DNS server.

Related Topics


Remove a server from the DNS console

Microsoft Windows graphic

To remove a server from the DNS console

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Delete.
  4. When prompted to confirm you want to delete this server from the list, click OK.

Notes

  • XOX
  • XOX

Related Topics


Manually update server data files

Microsoft Windows graphic

To manually update server data files

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Update Server Data Files.

Notes

  • XOX
  • XOX
  • For standard primary zones, this procedure causes the DNS server to immediately write its in-memory changes out to disk for storage with the zone file. Normally these changes are only written at predefined update intervals and when the DNS server is shut down.
  • For Active Directory–integrated zones, this procedure does not apply. To update Active Directory–integrated zones, see the command-line procedure below.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneUpdateFromDs ZoneName

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/ZoneUpdateFromDs | Required. Updates the zone file with data from Active Directory.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone you are updating.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneUpdateFromDs /help

  • The command-line procedure updates Active Directory–integrated zones only. For standard zones, see the Windows interface procedure above.
XOX
Related Topics


Change the boot method used by the DNS server

Microsoft Windows graphic

To change the boot method used by the DNS server

  1. Open DNS.
  2. In the console tree, right-click the applicable DNS server, then click Properties.
  3. Click the Advanced tab.
  4. In the Load zone data on startup list, select From registry, From file, or From Active Directory and registry.

Notes

  • XOX
  • XOX
  • By default, DNS servers use information stored in the registry to initialize for service and load any zone data for use at the server. As added options, you can configure the DNS server to boot from a file or, in Active Directory environments, you can supplement local registry data with zone data retrieved for directory-integrated zones stored in the Active Directory database. If you use the file method, the file used must be a text file named Boot, located on this computer in the systemroot\Windows\System32\Dns folder.

Related Topics


Change the name-checking method used by the DNS server

Microsoft Windows graphic

To change the name-checking method used by the DNS server

  1. Open DNS.
  2. In the console tree, right-click the applicable DNS server, then click Properties.
  3. Click the Advanced tab.
  4. In the Name checking list, select Strict RFC (ANSI), Non RFC (ANSI), Multibyte (UTF8), or All names.

Notes

  • XOX
  • XOX
  • The DNS Server service supports different possible methods for checking the names it receives and processes during normal operations:
    • Strict RFC (ANSI) This method strictly enforces RFC-compliant naming rules for all DNS names that the server processes. Names that are not RFC-compliant are treated as erred data by the server.
    • Non RFC (ANSI) This method allows names that are not RFC-compliant to be used with the DNS server, such as names that use ASCII characters but are not compliant with RFC host naming requirements.
    • Multibyte (UTF8) This method allows names that use the Unicode 8-bit translation encoding scheme, which is a proposed RFC draft, to be used with the DNS server.

      By default, the server uses Multibyte (UTF8) to check names.

    • All names Allows Non RFC (ANSI), Strict RFC (ANSI), and Multibyte (UTF8) naming conventions.

Related Topics


Restrict NS resource record registration

Microsoft Windows graphic

To restrict NS resource record registration

Using the Windows interface

  1. Open Registry Editor.

    2. Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
  2. In Registry Editor, navigate to the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

  3. Add the following REG_DWORD value:

    DisableNSRecordsAutoCreation

  4. Assign a value of 0x1.

    5. The REG_DWORD value is a local DNS server setting and applies to DNS zones for which this DNS server is authoritative.

Notes

  • XOX
  • XOX
  • This procedure restricts NS resource records registered for Active Directory domain controllers only.
  • To configure the DNS server to automatically add NS resource records corresponding to itself when loading a zone, you may assign a value of 0x0 or enter no value (default setting). This setting has the same effect as not creating the DisableNSRecordsAutoCreation registry entry.
  • If you have configured the registry to restrict the DNS server from registering NS resource records for authoritative zones, any existing NS resource records for the authoritative zones located on the DNS server are automatically deleted.
  • Regardless of the settings of these registry entries, query responses sent to DNS clients from the authoritative DNS server will indicate that the responses are from an authoritative DNS server.
  • The registry key entry described here does not exist by default and must be created and configured according to this procedure.

Using a command line

  1. Open Command Prompt.

    2. Caution

    • In this procedure you will be editing the registry. Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
  2. Type:

    dnscmd ServerName /Config /DisableNSRecordsAutoCreation 0x1

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/Config | Specifies the configuration command.
/DisableNSRecordsAutoCreation | Determines the local DNS server configuration for registering NS resource records for authoritative zones.
0x1 | Specifies that the DNS server specified in ServerName should not add NS resource records for authoritative zones. To specify that the DNS server should add NS resource records for all its authoritative zones, type a value of 0x0.

Notes

  • XOX
  • XOX
  • XOX
  • This procedure restricts NS resource records registered for Active Directory domain controllers only.
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /config /?

  • The DWORD value is a local DNS server setting and applies to authoritative DNS zones hosted on this DNS server.
  • Regardless of the settings above, query responses sent to DNS clients from authoritative DNS servers and selected domain controllers will indicate that the responses are from authoritative DNS servers.
  • To configure the DNS server to automatically add NS resource records corresponding to itself when loading a zone, you may assign a value of 0x0 or enter no value (default setting). This setting has the same effect as not creating the DisableNSRecordsAutoCreation registry entry.
  • If you have configured the registry to restrict the DNS server from registering NS resource records for authoritative zones, any existing NS resource records for the authoritative zones located on the DNS server are automatically deleted.
  • Regardless of a NS resource record registration setting, query responses sent to DNS clients from the authoritative DNS server will indicate that the responses are authoritative.
  • The registry key entries described here do not exist by default and must be created and configured using this procedure.
XOX

Related Topics


Allow NS resource record creation for specific domain controllers

Microsoft Windows graphic

To allow NS resource record creation for specific domain controllers

  1. Open Command Prompt.

    2. Important

    • This procedure applies to domain controller name server (NS) resource records in Active Directory–integrated DNS zones that are hosted on DNS servers configured to not add these resource records for their authoritative zones. For more information, see Related Topics.
  2. Type:

    dnscmd ServerName /Config ZoneName /AllowNSRecordsAutoCreation IpAddresses...

    3. Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/Config | Required. Specifies the configuration command.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
/AllowNSRecordsAutoCreation | Required. Specifies that domain controllers entered for Value will add their names to NS resource records for the zone specified in ZoneName.
IpAddresses... | Required. Specifies the IP addresses of the domain controllers that will add their names in NS resource records for the zone specified in ZoneName. Type a space-separated list of the IP addresses of the DNS servers. For example, 10.0.0.0 172.16.0.0 192.168.0.0.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /Config /?

  • If any domain controllers in the specified zone are not listed for IpAddresses..., their names will be deleted from the NS resource records for the zone specified in ZoneName.

    To specify that all domain controllers are allowed to add their names to NS resource records for the zone, or to clear the list of allowed DNS server IP addresses, type the command and omit IpAddresses...:

    dnscmd ServerName /Config ZoneName /AllowNSRecordsAutoCreation

  • Regardless of the settings above, query responses sent to DNS clients from authoritative DNS servers and selected domain controllers will indicate that the responses are from authoritative DNS servers.
XOX

Related Topics


Restrict DNS resource records updated by Net Logon

Microsoft Windows graphic

To restrict the DNS resource records updated by the Net Logon service

  1. Open Registry Editor.

    2. Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
  2. In Registry Editor, navigate to the following registry key:

    3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  3. Add the following multi-string value (REG_MULTI_SZ) value:

    4. DnsAvoidRegisterRecords

  4. In this value, specify the list of data corresponding to the DNS resource records that should not be registered for this domain controller by the Net Logon service. The list of data include:
    5. Data Value | Resource Record Type | DNS Resource Record
LdapIpAddress | A | <DnsDomainName>
Ldap | SRV | _ldap._tcp.<DnsDomainName>
LdapAtSite | SRV | _ldap._tcp.<SiteName>._sites.<DnsDomainName>
Pdc | SRV | _ldap._tcp.pdc._msdcs.<DnsDomainName>
Gc | SRV | _ldap._tcp.gc._msdcs.<DnsForestName>
GcAtSite | SRV | _ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsForestName>
DcByGuid | SRV | _ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName>
GcIpAddress | A | _gc._msdcs.<DnsForestName>
DsaCname | CNAME | <DsaGuid>._msdcs.<DnsForestName>
Kdc | SRV | _kerberos._tcp.dc._msdcs.<DnsDomainName>
KdcAtSite | SRV | _kerberos._tcp.dc._msdcs.<SiteName>._sites.<DnsDomainName>
Dc | SRV | _ldap._tcp.dc._msdcs.<DnsDomainName>
DcAtSite | SRV | _ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>
Rfc1510Kdc | SRV | _kerberos._tcp.<DnsDomainName>
Rfc1510KdcAtSite | SRV | _kerberos._tcp.<SiteName>._sites.<DnsDomainName>
GenericGc | SRV | _gc._tcp.<DnsForestName>
GenericGcAtSite | SRV | _gc._tcp.<SiteName>._sites.<DnsForestName>
Rfc1510UdpKdc | SRV | _kerberos._udp.<DnsDomainName>
Rfc1510Kpwd | SRV | _kpasswd._tcp.<DnsDomainName>
Rfc1510UdpKpwd | SRV | _kpasswd._udp.<DnsDomainName>

Important

  • This procedure restricts DNS resource records registered by the Net Logon service for Active Directory domain controllers only.

Notes

  • XOX
  • XOX
  • Restart of the Net Logon service is not required to make the changes to this value effective. If the DnsAvoidRegisterRecords registry key is created or modified while the Net Logon service is stopped or within the first 15 minutes after it is started, then appropriate DNS updates may take place with a short delay; however, the delay is no later than 15 minutes after the Net Logon service starts.

Related Topics


Optimize servers

  • Enable or disable fast transfer format during zone transfers
  • Prevent loading of a zone when bad data is found
  • Disable round-robin rotation for multihomed names
  • Disable local subnet prioritization for multihomed names
  • Restore server default preferences
  • Disable recursion on the DNS server
  • Update root hints on the DNS server
  • Secure server cache against names pollution
  • Clear the server names cache
  • Modify DNSSEC configuration
  • Modify EDNS0 configuration
  • Modify UDP message size


Enable or disable fast transfer format during zone transfers

Microsoft Windows graphic

To enable or disable fast transfer format during zone transfers

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. In the Server options list, select the BIND secondaries check box, and then click OK.

Notes

  • XOX
  • XOX
  • This setting is to be used only for optimizing zone transfers between Windows-based DNS servers and other DNS server implementations. Zone transfers between Windows-based DNS servers always use the fast transfer format.
  • DNS servers running versions of the Berkeley Internet Name Domain (BIND) server implementation prior to version 4.9.4 do not support the fast transfer format. You should enable this option only if you are transferring zones to BIND servers running version 4.9.4 or later.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /Config /BindSecondaries {1|0}

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/Config | Specifies the configuration command.
/BindSecondaries | Specifies use of fast transfer format used by legacy Berkeley Internet Name Domain (BIND) servers.
{1|0} | To enable fast transfer format when transferring a zone to legacy BIND DNS servers, type 1 (on). To disable fast transfer format, type 0 (off).

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd ServerName /Config /help

  • This setting is to be used only for optimizing zone transfers between Windows-based DNS servers and other DNS server implementations. Zone transfers between Windows-based DNS servers always use the fast transfer format.
  • DNS servers running versions of the Berkeley Internet Name Domain (BIND) server implementation prior to version 4.9.4 do not support the fast transfer format. You should enable this option only if you are transferring zones to BIND servers running version 4.9.4 or later.
XOX

Related Topics


Prevent loading of a zone when bad data is found

Microsoft Windows graphic

To prevent loading of a zone when bad data is found

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. In Server options, select the Fail on load if bad zone data check box, and then click OK.

Notes

  • XOX
  • XOX

Related Topics


Disable round-robin rotation for multihomed names

Microsoft Windows graphic

To disable round-robin rotation for multihomed names

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. In Server options, clear the Enable round robin check box, and then click OK.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /Config /RoundRobin {1|0}

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/Config | Specifies the configuration command.
/RoundRobin | Configures round robin rotation.
{1|0} | To enable round robin, type 1 (on). To disable round robin, type 0 (off).

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /Config /help

XOX

Related Topics


Disable local subnet prioritization for multihomed names

Microsoft Windows graphic

To disable local subnet prioritization for multihomed names

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. In Server options, clear the Enable netmask ordering check box, and then click OK.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /Config /LocalNetPriority {1|0}

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/Config | Specifies the configuration command.
/LocalNetPriority | Configures netmask ordering.
{1|0} | To enable netmask ordering, type 1 (on). To disable netmask ordering, type 0 (off).

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /Config /help

XOX

Related Topics


Restore server default preferences

Microsoft Windows graphic

To restore server default preferences

  1. Open DNS.
  2. In the console tree, right-click the applicable DNS server, and then click Properties.
  3. Click the Advanced tab.
  4. Click Reset to Default, and then click OK.

Notes

  • XOX
  • XOX
  • Clicking Reset to Default configures the DNS server with the initial configuration it had following installation. These setting are displayed in the table below.
    • Property | Setting
Disable recursion | Off
BIND secondaries | On
Fail on load if bad zone data | Off
Enable round robin | On
Enable netmask ordering | On
Secure cache against pollution | On
Name checking | Multibyte (UTF8)
Load zone data on startup | From Active Directory and registry
Enable automatic scavenging of stale records | Off

Related Topics


Disable recursion on the DNS server

Microsoft Windows graphic

To disable recursion on the DNS server

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable DNS server, then click Properties.
  3. Click the Advanced tab.
  4. In Server options, select the Disable recursion check box, and then click OK.

Notes

  • XOX
  • XOX
  • If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /Config /NoRecursion {1|0}

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/Config | Required. Specifies the configuration command.
/NoRecursion | Required. Specifies the command to disable recursion.
{1|0} | Required. To disable recursion, type 1 (off). To enable recursion, type 0 (on). By default, recursion is enabled.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /Config /help

  • If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.
XOX

Related Topics


Update root hints on the DNS server

Microsoft Windows graphic

To update root hints on the DNS server

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. Click the Root Hints tab.
  5. Modify server root hints as follows:
    • To add a root server to the list, click Add, and then specify the name and IP address of the server to be added to the list.
    • To modify a root server in the list, click Edit, and then specify the name and IP address of the server to be modified in the list.
    • To remove a root server from the list, select it in the list, and then click Remove.
    • To copy root hints from a DNS server, click Copy from server, and then specify the IP address of the DNS server from which you want to copy a list of root servers to use in resolving queries. These root hints will not overwrite any existing root hints.

Notes

  • XOX
  • XOX

Related Topics


Secure server cache against names pollution

Microsoft Windows graphic

To secure server cache against names pollution

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. In Server options, select the Secure cache against pollution check box, and then click OK.

Notes

  • XOX
  • XOX
  • The Secure cache against pollution option is enabled by default.

Related Topics


Clear the server names cache

Microsoft Windows graphic

To clear the server names cache

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Clear Cache.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /clearcache

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/clearcache | Required. Specifies the command to clear the DNS server cache.

Notes

  • XOX
  • XOX
  • XOX
XOX

Related Topics


Modify DNSSEC configuration

Microsoft Windows graphic

To modify DNSSEC configuration

  1. Open Registry Editor.

    2. Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
  2. In Registry Editor, navigate to the following registry subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

  3. Add the following DWORD entry:

    EnableDnsSec

  4. Do one of the following:
    • To exclude DNSSEC resource records in query responses other than responses to requests for SIG, KEY or NXT resource records, assign a value of 0x0. Appropriate resource records will be included in responses to requests for SIG, KEY, or NXT resource records only.
    • To include the DNSSEC resource records in all query responses (according to RFC 2535), assign a value of 0x2.
    • To include DNSSEC resource records only in cases where the original client query contained the OPT resource record (according to RFC 2671), assign a value of 0x1 or do not create the value at all. The DNS server behaves the same if the value is 0x1 or if the entry does not appear in the registry.

Notes

  • XOX
  • XOX
  • The value of the registry entry EnableDnsSec determines whether the DNS server will include or exclude DNSSEC resource records when it receives queries.

Related Topics


Modify EDNS0 configuration

Microsoft Windows graphic

To modify EDNS0 configuration

Using the Windows interface

  1. Open Registry Editor.

    2. Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
  2. In Registry Editor, navigate to the following registry subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

  3. Add the following DWORD entry:

    EDNSCacheTimeout

  4. To change the cache timeout, type a value in seconds between 3600 (1 hour) and 15724800 (182 days).
  5. In the same registry subkey (Parameters), add the following DWORD entry:

    EnableEDNSProbes

  6. To configure the DNS server to include an OPT resource record only in response to EDNS0 requests containing OPT resource records, type 0x1 (DWORD).
  7. Restart DNS server.

Notes

  • XOX
  • XOX
  • The value of the registry key EDNSCacheTimeout determines how long the DNS server will keep information about the EDNS versions supported by other DNS servers that have responded to a query with a OPT resource record.

Using a command line

  • Open Command Prompt.
  • Type one of the following:
    • dnscmd ServerName /Config /EDNSCacheTimeout Value
    • dnscmd ServerName /Config /EnableEDNSProbes Value
Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/Config | Required. Specifies the command to configure the DNS server.
/EDNSCacheTimeout | Required. Specifies the length of time the DNS server remembers the EDNS parameters remote servers report.
/EnableEdnsProbes | Required. Specifies whether or not the DNS server probes other DNS servers to determine if they support EDNS.
Value | Required. For /EDNSCacheTimeout, type a value in between 3600 (1 hour) and 15724800 (182 days). For /EnableEDNSProbes, type 1 to configure the DNS server to probe other DNS servers and determine if they support EDNS. Type 0 to configure the DNS server to not probe remote servers for EDNS support. If you type 0, the DNS server will continue to use EDNS if other servers request it.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /Config help

  • For information on the current registry setting, type one of the following:

    • dnscmd /Info /EDNSCacheTimeout

    • dnscmd /Info /EnableEDNSProbes

XOX

Related Topics


Modify UDP message size

Microsoft Windows graphic

To modify UDP message size

  1. Open Registry Editor.

    2. Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
  2. In Registry Editor, navigate to the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

  3. Add the following DWORD entry:

    MaximumUdpPacketSize

  4. Type a maximum UDP packet size value in bytes.

    The default value is 1280 bytes. The value must be between 512 and 16384 in decimal format (200 and 4000 in hexadecimal format).

  5. Restart DNS server.

Caution

  • When configuring the UDP packet size to be larger than 512 bytes, remember UDP packets must travel through devices other than UDP hosts, such as routers, and these devices may not support UDP packets larger than 512 bytes. It is recommended that you establish the maximum UDP packet length support for all devices, and the path's MTU, if possible, and configure your UDP hosts according to this maximum.

Notes

  • XOX
  • XOX
  • For information on discovering the maximum transmission unit (MTU) of an arbitrary Internet path, see Request for Comment (RFC) 1191, "Path MTU Discovery."

Related Topics


Monitor servers

  • Select and enable debug logging options on the DNS server
  • Disable debug logging options on the DNS server
  • Test a simple query on the DNS server
  • Test a recursive query on the DNS server
  • Enable automatic query testing on the DNS server
  • View the DNS server system event log
  • View a DNS server debug log file
  • Verify DNS server responsiveness using the nslookup command


Select and enable debug logging options on the DNS server

Microsoft Windows graphic

To select and enable debug logging options on the DNS server

  1. Open DNS.
  2. In the console tree, right-click the applicable DNS server, then click Properties.
  3. Click the Debug Logging tab.
  4. Select Log packets for debugging, and then select the events that you want the DNS server to record for debug logging.

Notes

  • XOX
  • XOX
  • To set the debug logging options, you must first select Log packets for debugging.
  • To get useful debug logging output you need to select a Packet direction, a Transport protocol and at least one more option.
  • In addition to selecting events for the DNS debug log file, you can specify the file name, location, and maximum file size for the file.
  • Using debug logging options slows DNS server performance. For this reason, all debug logging options are disabled by default.

Related Topics


Disable debug logging options on the DNS server

Microsoft Windows graphic

To disable debug logging options on the DNS server

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. Click the Debug Logging tab.
  5. Click Reset To Default, and then click OK.

Notes

  • XOX
  • XOX

Related Topics


Test a simple query on the DNS server

Microsoft Windows graphic

To test a simple query on the DNS server

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. Click the Monitoring tab.
  5. Select the A simple query against this DNS server check box.
  6. Click Test Now.

Notes

  • XOX
  • XOX
  • Results of the query test appear in Test results.

Related Topics


Test a recursive query on the DNS server

Microsoft Windows graphic

To test a recursive query on the DNS server

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. Click the Monitoring tab.
  5. Select the A recursive query to other DNS servers check box.
  6. Click Test Now.

Notes

  • XOX
  • XOX
  • Results of the query test appear in the Test results list box.

Related Topics


Enable automatic query testing on the DNS server

Microsoft Windows graphic

To enable automatic query testing on the DNS server

  1. Open DNS.
  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS
    • applicable DNS server
  3. On the Action menu, click Properties.
  4. Click the Monitoring tab.
  5. Select the type of testing to be used during automatic query testing. You can select one of both of the following:
    • A simple query against this DNS server
    • A recursive query to other DNS servers
  6. Select the Perform automatic testing at the following interval check box.
  7. Set the Test interval to be used.

    The query tests that you select are performed at regular intervals based on the value of the interval you specify. The default polling interval is 1 minute.

Notes

  • XOX
  • XOX
  • Results of automated query tests appear in Test results and are updated after each test interval.

Related Topics


View the DNS server system event log

Microsoft Windows graphic

To view the DNS server system event log

  1. Open DNS.
  2. In the console tree, click DNS Events.

    3. Where?

    • DNS
    • applicable DNS server
    • Event Viewer
    • DNS Events

Notes

  • XOX
  • XOX
  • If the DNS server for which you want to view the log is located on another computer, in the console tree, click DNS, and then on the Action menu, click Connect to DNS Server. Click The following computer, and then specify the name or IP address of the remote computer.
Related Topics


View a DNS server debug log file

Microsoft Windows graphic

To view a DNS server debug log file

  1. Stop the DNS Server service.
  2. Open WordPad.
  3. On the File menu, click Open.
  4. In Open, for File name, specify the path to the DNS server debug log file.

    By default, if the applicable DNS server is running locally, the file and path are as follows:

    systemroot \System32\Dns\Dns.log

  5. After you specify the correct path and file, click Open to view the log file.

Notes

  • XOX
  • XOX
  • To stop the DNS Server service, see Related Topics.
  • The location of the DNS.log file is managed using the DNS console. To specify the name and location of the DNS.log file, see Related Topics.
  • By default, the Dns.log file is empty if you have not previously enabled debug logging options.
  • Debug logging slows DNS server performance and should only be enabled for temporary use.

Related Topics


Verify DNS server responsiveness using the nslookup command

Microsoft Windows graphic

To verify DNS server responsiveness using the nslookup command

  1. Open Command Prompt.
  2. Type:

    3. nslookup server_ip_address 127.0.0.1

  3. If the server is responding, the name "localhost" is returned.

    If the server does not respond, continue troubleshooting the DNS server. For more information, see Related Topics.

Value | Description
nslookup | The name of the command-line program.
server_ip_address | The IP address of the DNS server at which you are verifying its responsiveness. For example, if the IP address of your DNS server is 10.0.0.1, you would type: nslookup 10.0.0.1 127.0.0.1

Note

  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    nslookup, press Enter and then type help

Related Topics


Add and remove zones

  • Add a forward lookup zone
  • Add a reverse lookup zone
  • Add a stub zone
  • Delete a zone
  • Pause a zone
  • Start a zone


Add a forward lookup zone

Microsoft Windows graphic

To add a forward lookup zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click a DNS server, and then click New Zone to open the New Zone Wizard.
  3. Follow the instructions to create a new primary, secondary, or stub zone.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneAdd ZoneName {/Primary|/DsPrimary|/Secondary|/Stub|/DsStub} [/file FileName] [/load] [/a AdminEmail] [/DP FQDN]

Value | Description
dsncmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZoneAdd | Required. Adds a zone.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
/Primary|/DsPrimary|
/Secondary|/Stub|/DsStub 		Required. Specifies the type of zone. /DsPrimary and /DsStub specify an Active Directory–integrated zone type.
/file | Required for /Primary. Specifies a file for the new zone. This parameter is invalid for the /DsPrimary zone type.
FileName | Required for /Primary. Specifies the name of the zone file. This parameter is invalid for the /DsPrimary zone type.
/load | Loads an existing file for the zone. Loads an existing file for the zone. If this parameter is not specified, default zone records are created automatically. This parameter does not apply to /DsPrimary.
/a | Adds an administrator e-mail address for the zone.
AdminEmail | Specifies the administrator email name for the zone.
/DP Adds the zone to an application directory partition. You may also use one of the following:
  • /DP /domain For domain directory partition (replicates to all DNS servers in the domain).
  • /DP /forest For forest directory partition (replicates to all DNS server in the forest).
  • /DP /legacy For legacy directory partition (replicates to all domain controllers in the domain). This setting supports domains using legacy Windows 2000 Server domain controllers.
FQDN | Specifies the fully qualified domain name of the directory partition.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneAdd /help

XOX

Related Topics


Add a reverse lookup zone

Microsoft Windows graphic

To add a reverse lookup zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click a DNS server, and then click New Zone to open the New Zone Wizard.
  3. Follow the instructions to create a new reverse lookup zone.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneAdd ZoneName {/Primary|/DsPrimary} [/file FileName] [/load] [/a AdminEmail] [/DP FQDN]

Value | Description
dsncmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZoneAdd | Required. Adds a zone.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the in-addr.arpa domain for the zone. For example, 20.1.168.192.in-addr.arpa..
/Primary|/DsPrimary | Required. Specifies the type of zone. To specify an Active Directory–integrated zone, type /DsPrimary.
/file | Required for /Primary. Specifies a file for the new zone. This parameter is invalid for the /DsPrimary zone type.
FileName | Required for /Primary. Specifies the name of the zone file. This parameter is invalid for the /DsPrimary zone type.
/load | Loads an existing file for the zone. Loads an existing file for the zone. If this parameter is not specified, default zone records are created automatically. This parameter does not apply to /DsPrimary.
/a | Adds an administrator e-mail address for the zone.
AdminEmail | Specifies the administrator email name for the zone.
/DP Adds the zone to an application directory partition. You may also use one of the following:
  • /DP /domain For domain directory partition (replicates to all DNS servers in the domain).
  • /DP /forest For forest directory partition (replicates to all DNS server in the forest).
  • /DP /legacy For legacy directory partition (replicates to all domain controllers in the domain). This setting supports domains using legacy Windows 2000 Server domain controllers.
FQDN | Specifies the fully qualified domain name of the directory partition.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneAdd /help

XOX

Related Topics


Add a stub zone

Microsoft Windows graphic

To add a stub zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click a DNS server, and then click New Zone to open the New Zone Wizard.
  3. Follow the instructions to create a new stub zone.

Notes

  • XOX
  • XOX
  • The stub zone cannot be hosted on a DNS server that is authoritative for the same zone.
  • If you choose to integrate the stub zone into Active Directory (using Active Directory as the stub zone's storage method), you have the option to specify that the DNS server hosting the stub zone use a local list of master servers when updating the stub zone's resource records, rather than have the DNS server use the master servers list stored in Active Directory. If you want to use a local master servers list, you will need the IP addresses of the local master servers.
  • If you want the DNS server hosting a stub zone to use a local list of master servers, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneAdd ZoneName {/Stub|/DsStub} MasterIPaddress... [/file FileName] [/load] [/DP FQDN]

Value | Description
dsncmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZoneAdd | Required. Adds a zone.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
/Stub|/DsStub | Required. Specifies the type of zone. To specify an Active Directory–integrated stub zone, type /DsStub.
MasterIPaddress... | Required. Specifies one or more IP addresses for the master servers of the stub zone, from which it copies zone data.
/file | Adds a file for the new zone.
FileName | Specifies the name of the zone file.
/load | Loads an existing file for the zone. If this parameter is not specified, default zone records are created automatically.
/DP Adds the zone to an application directory partition. You may also use one of the following:
  • /DP /domain For domain directory partition (replicates to all DNS servers in the domain).
  • /DP /forest For forest directory partition (replicates to all DNS server in the forest).
  • /DP /legacy For legacy directory partition (replicates to all domain controllers in the domain). This setting supports domains using legacy domain controllers running Windows 2000 Server.
FQDN | Specifies the fully qualified domain name of the directory partition.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneAdd /help

  • The stub zone cannot be hosted on a DNS server that is authoritative for the same zone.
  • If you choose to integrate the stub zone into Active Directory (using Active Directory as the stub zone's storage method), you have the option to specify that the DNS server hosting the stub zone use a local list of master servers when updating the stub zone's resource records, rather than have the DNS server use the master servers list stored in Active Directory. If you want to use a local master servers list, you will need the IP addresses of the local master servers.
  • If you want the DNS server hosting a stub zone to use a local list of master servers, see Related Topics.
XOX

Related Topics


Delete a zone

Microsoft Windows graphic

To delete a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable zone.

    Where?

    • DNS
    • applicable DNS server
    • Forward Lookup Zones (or Reverse Lookup Zones)
    • applicable zone
  3. On the Action menu, click Delete.
  4. When asked to confirm that you want to delete the zone, click OK.

Caution

  • Deleting an Active Directory–integrated zone effectively deletes the zone and eliminates its use at all other DNS servers using the same directory store of zone data.

Notes

  • XOX
  • XOX
  • This procedure is most often used to delete a secondary copy of a zone, although it can also be used to delete a primary zone.
  • Deleting a standard primary zone is usually unnecessary, unless you are redesigning your DNS namespace and the zone is no longer needed or used. In most cases, you can change the zone type if you only want to modify the zone. For more information, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneDelete ZoneName [/DsDel] [/f]

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZoneDelete | Required. Specifies the command to delete the zone specified by ZoneName.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone you are deleting.
/DsDel | Deletes a the zone from Active Directory.
/f | Performs the command without asking for confirmation. If you omit this parameter, you are prompted to confirm the deletion of the resource record.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneDelete /help

XOX

Related Topics


Pause a zone

Microsoft Windows graphic

To pause a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable zone.

    Where?

    • DNS
    • applicable DNS server
    • Forward Lookup Zones (or Reverse Lookup Zones)
    • applicable zone
  3. On the Action menu, click Properties.
  4. On the General tab, click Pause, and then click OK.

Notes

  • XOX
  • XOX
  • By default, zones are started when created or loaded at the server. Once you use this procedure to pause a zone, you must restart the zone before it is available for servicing clients or zone updates.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZonePause ZoneName

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZonePause | Required. Pauses the zone.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.

Notes

  • XOX
  • XOX
  • XOX
XOX

Related Topics


Start a zone

Microsoft Windows graphic

To start a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable zone.

    Where?

    • DNS
    • applicable DNS server
    • Forward Lookup Zones (or Reverse Lookup Zones)
    • applicable zone
  3. On the Action menu, click Properties.
  4. On the General tab, click Start, and then click OK.

Notes

  • XOX
  • XOX
  • By default, zones are started when created or loaded at the server. Only zones that have previously been paused need to be restarted.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneResume ZoneName

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZoneResume | Required. Resumes the hosting of the zone by the DNS server.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone resuming operation.

Notes

  • XOX
  • XOX
  • By default, zones are started when created or loaded at the server. Only zones that have previously been paused need to be restarted.
XOX

Related Topics


Configure zone properties

  • Change the zone type
  • Change a zone file name
  • Change zone replication scope
  • Modify the start of authority (SOA) record for a zone
  • Modify zone transfer settings
  • Create and manage a notify list for a zone
  • Create a zone delegation
  • Verify a zone delegation using the nslookup command
  • Configure a stub zone for local master servers
  • Specify other DNS servers as authoritative for a zone
  • Update the master server for a secondary zone
  • Enable DNS to use WINS resolution
  • Verify WINS as the source for answering a DNS query


Change the zone type

Microsoft Windows graphic

To change the zone type

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone and choose Properties.
  3. On the General tab, note the current zone type, then click Change.
  4. In Change Zone Type, select a zone type other than the current one, and then click OK.

Notes

  • XOX
  • XOX
  • You can select from Primary zone, Secondary zone or Stub zone. When selecting the secondary or stub zone types, you must specify the IP address of another DNS server to be used as the source for obtaining updated information for the zone.
  • If the DNS server computer is operating as a domain controller, the option to change the zone type to Active Directory–integrated is available. This option is not otherwise available. When this zone type is selected for use, zone data is stored and replicated as part of the Active Directory database.
  • Changing a zone from secondary to primary type can affect other zone activities, including management of dynamic updates and zone transfers, and the use of DNS notify lists to notify other servers about changes in the zone. For more information, see Related Topics.
  • Changing a zone from stub to primary type or vice versa is not recommended due to the purpose of stub zones. For more information, see Related Topics.
  • Changing DNS zone type or storage can be time-consuming for large zones.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneResetType ZoneName Property [MasterIPaddress...] [/file FileName] {/OverWrite_Mem|/OverWrite_Ds|/DirectoryPartition FQDN}

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of zone.
Property Required. One of the following zone types:
  • /Primary
    Standard primary zone. The FileName must be required.
  • /DsPrimary
    Active Directory–integrated primary zone.
  • /Secondary
    Secondary zone. You must specify at least one MasterIPaddress....
  • /Stub
    Stub zone. You must specify at least one MasterIPaddress....
  • /DsStub
    Active Directory–integrated stub zone. You must specify at least one MasterIPaddress....
/file | Required for /Primary. Specifies a file for the new zone. This parameter is invalid for the /DsPrimary zone type.
FileName | Required for /Primary. Specifies the name of the zone file. This parameter is invalid for the /DsPrimary zone type.
MasterIPaddress... | Required for /Secondary, /Stub and /DsStub. Specifies one or more IP addresses for the master servers of the secondary or stub zone, from which it copies zone data.
/OverWrite_Mem|/OverWrite_Ds|/DirectoryPartition FQDN | /OverWrite_Mem overwrites exisiting DNS data using the data in Active Directory. /OverWrite_Ds overwrites Active Directory data with data in DNS. /DirectoryPartition stores the new zone in the application directory partition specified by FQDN, such as DomainDnsZones.corp.example.microsoft.com.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneResetType /help

  • You can select from primary , secondary or stub zone. When selecting the secondary or stub zone type, you need to specify the IP address of another DNS server to be used as the source for obtaining updated information for the zone.
  • If the DNS server computer is operating as a domain controller, the option to change the zone type to Active Directory–integrated is available. This option is not otherwise available. When this zone type is selected for use, zone data is stored and replicated as part of the Active Directory database.
  • Changing a zone from secondary to primary type can affect other zone activities, including management of dynamic updates and zone transfers, and the use of DNS notify lists to notify other servers about changes in the zone. For more information, see Related Topics.
  • Changing a zone from stub to primary type or vice versa is not recommended due to the purpose of stub zones. For more information, see Related Topics.
XOX

Related Topics


Change a zone file name

Microsoft Windows graphic

To change a zone file name

  1. Open DNS.
  2. In the console tree, click the applicable zone.

    Where?

    • DNS
    • applicable DNS server
    • Forward Lookup Zones (or Reverse Lookup Zones)
    • applicable zone
  3. On the Action menu, click Properties.
  4. On the General tab, in the Zone file name text box, type the new file name for this zone.
  5. Click OK when you have finished entering the new zone file name.

Caution

  • If the zone file name is changed, be sure to update Zone file name on other DNS servers that maintain this zone. Otherwise, subsequent zone transfers and updates might fail. This can occur in the following situations:
    • The zone type is primary on this server.
    • The zone type is secondary on this server and this server acts as a source or master server for this zone to other DNS servers that host secondary copies of this zone.

Notes

  • XOX
  • XOX
  • The name of the zone file changes, not the name of the zone. You can use Windows Explorer to view or verify the new zone file name.
  • The zone file name is not used for Active Directory–integrated zones because these zones store zone data in the Active Directory database and not a text file on the DNS server computer.

Related Topics


Change zone replication scope

Microsoft Windows Graphic

To change zone replication scope

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone, and then click Properties.
  3. On the General tab, note the current zone replication type, and then click Change.
  4. Select a replication scope for the zone.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Only Active Directory–integrated primary and stub forward lookup zones can change their replication scope. Secondary forward lookup zones cannot change their replication scope.
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneChangeDirectoryPartition ZoneName NewPartitionName

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZoneChangeDirectoryPartition | Required. Changes a zone's replication scope.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NewPartitionName | Required. The FQDN of the DNS application directory partition where the zone will be stored.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneChangeDirectoryPartition /?

  • Only Active Directory–integrated primary forward lookup zones and Active Directory–integrated stub zones can change their replication scope. Secondary forward lookup zones cannot change their replication scope.
  • XOX
XOX

Related Topics


Modify the start of authority (SOA) record for a zone

Microsoft Windows graphic

To modify the start of authority (SOA) record for a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone, and then click Properties.
  3. Click the Start of Authority (SOA) tab.
  4. As needed, modify properties for the start of authority (SOA) record.

Notes

  • XOX
  • XOX
  • The settings applied for the start of authority (SOA) record affect how zone transfers are made between servers. For more information, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [Ttl] SOA PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/RecordAdd | Required. Adds or modifies a resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace for which the SOA record is added. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | Specifies that this resource record is able to be aged and scavenged. If this parameter is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time to Live (TTL) setting for the resource record. (The default TTL is defined in SOA resource record).
SOA | Required. Specifies the type of resource record you are modifying.
PrimSvr | Required. Specifies the FQDN name of the server that is the primary source for information about the zone. For example, nameserver.place.example.microsoft.com.
Admin | Required. Specifies the name of the DNS administrator for the zone. For example, postmaster.nameserver.place.example.microsoft.com.
Serial#\ | Required. Specifies the version information for the zone.
Refresh | Required. Specifies the refresh interval for the zone. The standard setting is 3600 (one hour).
Retry | Required. Specifies the retry interval for the zone. The standard setting is 600 (ten minutes).
Expire | Required. Specifies the expire interval for the zone. The standard setting is 86400 (one day).
MinTTL | Required. Specifies the minimum Time to Live (TTL) value. This is the length of time used by other DNS servers to determine how long to cache information for a record in the zone before expiring and discarding it. The standard setting is 3600 (one hour).

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

  • To modify any specific SOA resource record's values using dnscmd, you must specify all of the SOA values (PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL).
XOX

Related Topics


Modify DNS zone transfer settings

Microsoft Windows Graphic

To modify DNS zone transfer settings

Using the Windows interface

  1. Open DNS.
  2. Right-click a DNS zone, and then click Properties.
  3. On the Zone Transfers tab, do one of the following:.
    • To disable zone transfers, clear the Allow zone transfers check box.
    • To allow zone transfers, select the Allow zone transfers check box.
  4. If you allowed zone transfers, do one of the following:
    • To allow zone transfers to any server, click To any server.
    • To allow zone transfers only to the DNS servers listed on the Name Servers tab, click Only to servers listed on the Name Servers tab.
    • To allow zone transfers only to specific DNS servers, click Only to the following servers, and then add the IP address of one or more DNS servers.

Notes

  • XOX
  • XOX
  • To improve the security of your DNS infrastructure, zone transfers should only be allowed for either the DNS servers in the name server (NS) resource records for a zone or for specified DNS servers. If you allow any DNS server to perform a zone transfer, you are allowing internal network information to be transferred to any host that can contact your DNS server.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneResetSecondaries ZoneName {/NoXfr | /NonSecure | /SecureNs | /SecureList [SecondaryIPAddress...]}

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of zone.
/NoXfr | Disables zone transfers for the zone.
/NonSecure | Permits zone transfers to any DNS server.
/SecureNs | Permits zone transfers only to DNS servers listed in the zone using name server (NS) resource records.
/SecureList | Permits zone transfers only to DNS servers specified by SecondaryIPAddress.
SecondaryIPAddress | Required, if /SecureList is specified. A list of one or more IP addresses for DNS servers that are permitted to obtain zone transfers.

Notes

  • XOX
  • XOX

  • XOX

  • To view the complete syntax for this command, at a command prompt, type:
    dnscmd /ZoneResetSecondaries /?
  • To improve the security of your DNS infrastructure, zone transfers should only be allowed for either the DNS servers in the NS resource records for a zone or for specified DNS servers. If you allow any DNS server to perform a zone transfer, you are allowing internal network information to be transferred to any host that can contact your DNS server.
XOX

Related Topics


Create and manage a notify list for a zone

Microsoft Windows graphic

To create and manage a notify list for a zone

  1. Open DNS.
  2. In the console tree, click the applicable zone.

    Where?

    • DNS
    • applicable DNS server
    • Forward Lookup Zones (or Reverse Lookup Zones)
    • applicable zone
  3. On the Action menu, click Properties.
  4. Click the Zone Transfers tab.
  5. Click Notify.
  6. Verify that the Automatically notify check box is checked.
  7. Select the method to be used for creating a list for notifying other DNS servers when changes to the zone occur. Your options are:
    • Use the default, Servers listed on the Name Servers tab, to permit only those servers that appear by IP address on the Name Servers tab to be included in the notify list.
    • Select The following servers if you want to specify a different notify list to be used instead.
  8. If you selected The following servers in the previous step, add or remove server IP addresses to form the notify list as needed:
    • To add a server to the notify list, type its IP address in the IP address field and click Add.
    • To remove a server from the notify list, click the server IP address in the list box and click Remove.

Notes

  • XOX
  • XOX
  • Changes to the notify list properties are only available on primary zones. For secondary zones, these properties are read-only. DNS Notify is an RFC-compliant extension of the DNS standard defined in RFC 1996, "A Mechanism for Prompt Notification of Zone Changes."
  • By default, the DNS server will only allow a zone transfer to authoritative DNS servers listed in the name server (NS) resource records for the zone.

Related Topics


Create a zone delegation

Microsoft Windows graphic

To create a zone delegation

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable subdomain, and then click New Delegation.
  3. Follow the instructions provided in the New Delegation wizard to finish creating the new delegated domain.

Notes

  • XOX
  • XOX
  • All domains (or subdomains) that appear as part of the applicable zone delegation must be created in the current zone prior to performing delegation as described here. As necessary, use the DNS console to first add domains to the zone before completing this procedure. For more information, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [/OpenAcl] [Ttl] NS {HostName|FQDN}

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/RecordAdd | Required. Specifies the command to add a resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace for which the SOA record is added. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | If this command is used, this resource record is able to be aged and scavenged. If this command is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time-To-Live (TTL) setting for the resource record. (The default TTL is defined in SOA resource record).
NS | Required. Specifies that you are adding a name server (NS) resource record to the zone specified in ZoneName.
HostName|FQDN | Required. Specifies the host name or FQDN of the new authoritative server.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

XOX

Related Topics


Verify a zone delegation using the nslookup command

Microsoft Windows graphic

To verify a zone delegation using the nslookup command

  1. Open Command Prompt.
  2. Type:

    3. nslookup RootServerIpAddress

  3. Then type:

    4. nslookup

  4. At the next prompt, type:

    5. set norecurse

  5. At the next prompt, type:

    6. set q=NS

  6. Type the fully qualified domain name (FQDN) for the failed name.

    Use the trailing period (.) when entering the name. If zone delegations are set correctly, a list of name server (NS) resource records for delegated servers should be returned in the response.

  7. If the NS query response contains no names or IP addresses for delegated servers, type q=ns and query again using the FQDN for the parent zone of the failed name.

    For example, if the failed name you used in the previous step was example.microsoft.com, query for microsoft.com.

  8. If the response contains NS resource records, but no host (A) resource records, type set recurse and query individually for any of the A resource records of servers listed in the NS resource records.

    If, for each NS resource record you encounter in a zone, you do not find at least one valid IP address in an A resource record, you have a broken delegation.

  9. Either fix the broken delegation or retry the delegation test described in the previous step using a different IP address.

    If more than one A resource record or IP address is found, use it to repeat the delegation test described in the previous step. To fix a delegation, add or update an A resource record in the parent zone with a valid IP address for a correct DNS server for the delegated zone.

Value | Description
nslookup | The name of the command-line tool.
root_server_ip_address | The IP address of a valid root server for your network.
set norecursion | A command to instruct the root server to not perform recursion on your query.
set q=NS | The command to send the query for NS resource records to the root server.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    nslookup, press Enter and then type help

Related Topics


Configure a stub zone to use local master servers

Microsoft Windows graphic

To configure a stub zone to use local master servers

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the stub zone, and then click Properties.
  3. On the General tab, under IP address, modify the list to display the IP addresses of the local master servers that you want the DNS server to use when loading and updating the stub zone.

    Ensure that the IP addresses of the local master servers are for only those authoritative DNS servers that should be queried to update the records of the stub zone on this server.

  4. Select the Use the list above as a local list of masters check box, and then click OK.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • If the local list of master servers is cleared at a later date, the master servers list from Active Directory is applied and the local list of master servers is deleted.
  • When modifications to the master servers list are made and applied on a domain controller hosting the stub zone, the list of master servers for the stub zone is updated in Active Directory.
  • The DNS server will keep the master servers list from Active Directory stored in memory.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneResetMasters ZoneName [/Local] [MasterIPaddress...]

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
/Local | Configures the local master list for Active Directory–integrated zones.
MasterIPaddress... | List of one or more IP addresses of master servers for this zone. Master servers may include the server hosting the primary zone or servers hosting other secondary copies for the zone. To clear the local list of masters, type the command without entering any IP addresses. Ensure that the IP addresses of the local master servers are for only those authoritative DNS servers that should be queried to update the records of the stub zone on this server.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneResetMasters /help

  • If the local list of master servers is cleared at a later date, the master servers list from Active Directory is applied and the local list of master servers is deleted.
  • When modifications to the master servers list are made and applied on a domain controller hosting the stub zone, the list of master servers for the stub zone is updated in Active Directory.
  • The DNS server will keep the master servers list from Active Directory stored in memory.
XOX

Related Topics


Specify other DNS servers as authoritative for a zone

Microsoft Windows graphic

To specify other DNS servers as authoritative for a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone, and then click Properties.
  3. Click the Name Servers tab.
  4. Click Add.
  5. Specify additional DNS servers by their names and IP addresses, and then click Add to add them to the list.

Notes

  • XOX
  • XOX
  • To add a name server to the list of authoritative servers for the zone, you must specify both the server's IP address and its DNS name. When entering names, click Resolve to resolve the name to its IP address prior to adding it to the list.
  • DNS servers specified using this procedure are added to those server IP addresses already present for the existing name server (NS) resource record for the zone. Typically, you might only need to perform this procedure at the primary zone when adding DNS servers to act as secondary servers and also to specify that these servers are known to be authoritative when answering queries for zone data.
  • DNS servers automatically add and perform initial configuration of the NS resource record for each new primary zone added to the server.

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [/OpenAcl] [Ttl] NS {HostName|DomainName}
Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/RecordAdd | Required. Specifies the command to add a resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace for which the SOA record is added. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | If this command is used, this resource record is able to be aged and scavenged. If this command is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time-To-Live (TTL) setting for the resource record. (The default TTL is defined in SOA resource record).
NS | Required. Specifies that you are adding a name server (NS) resource record to the zone specified in ZoneName.
HostName|FQDN | Required. Specifies the host name or FQDN of the new authoritative server.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

  • DNS servers specified using this procedure are added to those server IP addresses already present for the existing name server (NS) resource record for the zone. Typically, you might only need to perform this procedure at the primary zone when adding DNS servers to act as secondary servers and also to specify that these servers are known to be authoritative when answering queries for zone data.
  • DNS servers automatically add and perform initial configuration of the NS resource record for each new primary type added to the server.
XOX

Related Topics


Update the master server for a secondary zone

Microsoft Windows graphic

To update the master server for a secondary zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable secondary zone, and then click Properties.
  3. On the General tab, in IP address, specify the IP address for a new master server, and then click Add to update the list.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneResetMasters ZoneName [/Local] MasterIPaddress...

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZoneResetMasters | Required. Updates the master servers for a secondary zone.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone you are updating.
/Local | Specifies the local master list for Active Directory–integrated zones.
MasterIPaddress... | Required. Specifies the IP addresses of the master servers to be used by the DNS server when updating the specified secondary zones. If you do not specify ServerIPs, you are requesting the DNS server to reset the value to an empty list. The request may be denied because a zone must always have at least one master server. MasterIPaddress... is required to clear the local master list for a zone.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneResetMasters /help

XOX

Related Topics


Enable DNS to use WINS resolution

Microsoft Windows graphic

To enable DNS to use WINS resolution

  1. Open DNS.
  2. In the console tree, right-click the applicable zone, then click Properties.
  3. Do one of the following:
    • If the applicable zone is a forward lookup zone, on the WINS tab, select the Use WINS forward lookup check box. In IP address, type the IP address of a WINS server to be used for resolution of names not found in DNS, and then click Add.
    • If the applicable zone is a reverse lookup zone, on the WINS-R tab, select the Use WINS-R lookup check box. In Domain to append to returned name, type a name.
  4. Select the Do not replicate this record check box for this WINS record, if applicable.

    If you are replicating this zone between DNS servers that do not recognize the WINS or WINS-R resource records, click this check box. This prevents these records from being replicated to these other servers during zone transfers. If this zone will be used in performing zone transfers to BIND servers, this is a critical option as BIND will not recognize WINS records.

Notes

  • XOX
  • XOX
  • When this option is used, specified WINS servers configured in this procedure are used for final referral of names not found in the applicable zone.
  • Optionally, click Advanced to adjust advanced WINS lookup parameters.

Related Topics


Verify WINS as the source for answering a DNS query

Microsoft Windows graphic

To verify WINS as the source for answering a DNS query

  1. Open Command Prompt.
  2. Type:

    nslookup

  3. After the previous command completes, at the nslookup ("") prompt type:

    4. set debug

  4. Next, either type:

    set querytype=a

    if you are testing for a WINS forward lookup, or:

    set querytype=ptr

    if you are testing for a WINS-R reverse lookup.

    Respectively, these two commands can be used to set the query type to filter either by host (A) or pointer (PTR) resource records as appropriate for researching either a forward or reverse lookup.

  5. Based on whether you are verifying possible WINS sourcing for either a forward or reverse lookup, type the appropriate fully qualified domain name (FQDN).

    For example, if the forward lookup you are tracing is for a domain name host-a.example.microsoft.com, type:

    host-a.example.microsoft.com.

    If the reverse lookup you are tracing is for an IP address 10.0.0.1, type:

    1.0.0.10.in-addr.arpa.

  6. In the response, note whether the server answered authoritatively or non-authoritatively, and note the Time-To-Live (TTL) value.
  7. If the server answered authoritatively, repeat the same query you performed in step 4.
  8. In the response, note whether the TTL value decreased with the second query answer or if it remained consistent with the TTL value specified in the first query answer.

    If the TTL value decreased for an authoritatively answered query, the source of the query answer is a WINS server.

  9. To leave debug mode and return to the command prompt, type exit.
Value | Description
nslookup | The name of the command-line program.
set debug

Enables the nslookup command to operate in debug mode, providing extended information in the command output.

This mode is required to view query response information about whether the source for a query answer is:

  • authoritative (from a DNS zone or WINS server database)
  • non-authoritative (cached data from previous queries made by the DNS server or loaded from root hints)
set querytype | Changes the type of information query. More information about types can be found in Request For Comment (RFC) 1035.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    nslookup, press Enter and then type help

  • Normally, when a DNS server answers a query from its authoritative zone data, it uses the set minimum or default TTL for the zone or the record-specific TTL value (if one is configured). In so doing, TTLs are decreased in answers the server returns if based on non-authoritative data, such as a cached record at the server.

    WINS lookups present an exceptional case, where an answer received back from a WINS server is cached by the DNS server but is also considered to be authoritative data. In this case, the WINS sourced data is returned to clients as authoritative but ages while in the DNS server names cache, causing the TTL used by the server to decrease over time.

Related Topics


Manage zones

  • Allow dynamic updates
  • Allow only secure dynamic updates
  • Initiate a zone transfer at a secondary server
  • Reload or transfer a stub zone
  • Adjust the refresh interval for a zone
  • Adjust the retry interval for a zone
  • Adjust the expire interval for a zone
  • Modify security for a directory-integrated zone


Allow dynamic updates

Microsoft Windows graphic

To allow dynamic updates

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone, and then click Properties.
  3. On the General tab, verify that the zone type is either Primary or Active Directory–integrated.
  4. In Dynamic Updates, click Nonsecure and secure.

Notes

  • XOX
  • XOX
  • Dynamic update is an RFC-compliant extension to the DNS standard. The DNS update process is defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATES)."

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /Config {ZoneName|..AllZones} /AllowUpdate {1|0}

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/Config | Required. Specifies the configuration command.
ZoneName|..AllZones | Required. Specifies the fully qualified domain name (FQDN) of the zone. To configure all zones hosted on the specified DNS server to allow dynamic updates, type ..AllZones.
/AllowUpdate | Required. Specifies the allow update command.
1|0 | Configures dynamic update. To allow dynamic updates, enter a value of 1. To not allow dynamic updates, enter a value of 0.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /Config /help

  • Dynamic update is an RFC-compliant extension to the DNS standard. The DNS update process is defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATES)."
XOX

Related Topics


Allow only secure dynamic updates

Microsoft Windows graphic

To allow only secure dynamic updates

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone and click Properties.
  3. On the General tab, verify that the zone type is Active Directory–integrated.
  4. In Dynamic Updates, click secure only.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Secure dynamic update is supported only for Active Directory–integrated zones. If the zone type is configured differently, you must change the zone type and directory integrate the zone prior to securing it for DNS dynamic updates.
  • Dynamic update is an RFC-compliant extension to the DNS standard. The DNS update process is defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)."
  • By default, the DNS server will only allow a zone transfer to authoritative DNS servers listed in the name server (NS) resource records for the zone.
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /Config {ZoneName|..AllZones} /AllowUpdate 2

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/Config | Required. Specifies the configuration command.
ZoneName|..AllZones | Required. Specifies the fully qualified domain name (FQDN) of the zone. To configure all zones hosted on the specified DNS server to allow dynamic updates, type ..AllZones.
/AllowUpdate | Required. Specifies the allow update command.
2 | Required. Configures server to allow secure update. If you exclude the 2, the zone will be set to perform standard dynamic updates only.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /Config /help

  • Dynamic update is an RFC-compliant extension to the DNS standard. The DNS update process is defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)."
  • By default, the DNS server will only allow a zone transfer to authoritative DNS servers listed in the name server (NS) resource records for the zone.
  • XOX
XOX

Related Topics


Initiate a zone transfer at a secondary server

Microsoft Windows graphic

To initiate a zone transfer at a secondary server

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone and click Transfer from master.

Notes

  • XOX
  • XOX
  • This procedure checks to see if the start of authority (SOA) resource record in the secondary zone is the most recent version of the SOA resoure record in the primary zone. If the SOA resource records are synchronized, then there is no zone transfer. If the SOA resource records are not synchronized, then there is a zone transfer.
  • By default, the DNS server will only allow a zone transfer to authoritative DNS servers listed in the name server (NS) resource records for the zone.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /ZoneRefresh ZoneName

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZoneRefresh | Required. Updates the secondary zone.
ZoneName | Required. Specifies the name of the secondary zone to update.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneRefresh /help

  • This procedure checks to see if the start of authority (SOA) resource record in the secondary zone is the most recent version of the SOA resoure record in the primary zone. If the SOA resource records are synchronized, then there is no zone transfer. If the SOA resource records are not synchronized, then there is a zone transfer.
  • By default, the DNS server will only allow a zone transfer to authoritative DNS servers listed in the name server (NS) resource records for the zone.
XOX

Related Topics


Reload or transfer a stub zone

Microsoft Windows graphic

To reload or transfer a stub zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable stub zone, and do one of the following:
    • To reload the stub zone from storage, click Reload.
    • To have the DNS server determine if the serial number in the stub zone's SOA resource record has expired and then perform a zone transfer from the stub zone's master server, click Transfer from Master.
    • To perform a zone transfer from the stub zone's master server regardless of the serial number in the stub zone's SOA resource record, click Reload from Master.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName {/ZoneReload|/ZoneUpdateFromDs|/ZoneRefresh} ZoneName

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZoneReload | Reloads the stub zone.
/ZoneUpdateFromDs | Reloads the stub zone from Active Directory.
/ZoneRefresh | Refreshes the stub zone. The DNS server will determine if the serial number in the stub zone's SOA resource record has expired. If the serial number has expired, the DNS server will perform a zone transfer from the stub zone's master server.
ZoneName | Required. Specifies the name of the stub zone you want to reload or refresh.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneReload /help or dnscmd /ZoneUpdateFromDs /help or dnscmd /ZoneRefresh /help.

  • There is no dnscmd command to perform a zone transfer regardless of the SOA resource record's expiration date. To perform this operation, use the Windows interface procedure.
XOX

Related Topics


Adjust the refresh interval for a zone

Microsoft Windows graphic

To adjust the refresh interval for a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone and click Properties.
  3. On the General tab, verify that the zone type is either Primary or Active Directory–integrated.
  4. Click the Start of Authority (SOA) tab.
  5. In Refresh interval, click a time period in minutes, hours, or days, and type a number in the text box.
  6. Click OK to save the adjusted interval.

Notes

  • XOX
  • XOX
  • By default, the refresh interval for each zone is set to 1 hour. The refresh interval is used to determine how often other DNS servers that load and host the zone must attempt to renew the zone.

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /RecordAdd Zone NodeName [/Aging] [Ttl] SOA PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL
Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/RecordAdd | Required. Adds or modifies a resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace for which the SOA record is added. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | Specifies that this resource record is able to be aged and scavenged. If this parameter is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time-To-Live (TTL) setting for the resource record. (The default TTL is defined in SOA resource record).
SOA | Required. Specifies the type of resource record you are modifying.
PrimSvr | Required. Specifies the FQDN name of the server that is the primary source for information about the zone. For example, nameserver.place.example.microsoft.com.
Admin | Required. Specifies the name of the DNS administrator for the zone. For example, postmaster.nameserver.place.example.microsoft.com.
Serial#\ | Required. Specifies the version information for the zone.
Refresh | Required. Specifies the refresh interval for the zone. The standard setting is 3600 (one hour).
Retry | Required. Specifies the retry interval for the zone. The standard setting is 600 (ten minutes).
Expire | Required. Specifies the expire interval for the zone. The standard setting is 86400 (one day).
MinTTL | Required. Specifies the minimum Time-To-Live value. This is the length of time used by other DNS servers to determine how long to cache information for a record in the zone before expiring and discarding it. The standard setting is 3600 (one hour).

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

  • To modify any specific SOA resource record's values using dnscmd, you must specify all of the SOA values (PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL).
  • By default, the refresh interval for each zone is set to 1 hour. The refresh interval is used to determine how often other DNS servers that load and host the zone must attempt to renew the zone.
XOX

Related Topics


Adjust the retry interval for a zone

Microsoft Windows graphic

To adjust the retry interval for a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone and click Properties.
  3. On the General tab, verify that the zone type is either Primary or Active Directory–integrated.
  4. Click the Start of Authority (SOA) tab.
  5. In Retry interval, click an interval in minutes, hours, or days, and type a number in the text box.
  6. Click OK to save the adjusted interval.

Notes

  • XOX
  • XOX
  • By default, the retry interval for each zone is set at 10 minutes. The retry interval is used to determine how often other DNS servers that load and host the zone are to retry a request for update of the zone each time the refresh interval occurs.

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /RecordAdd Zone NodeName [/Aging] [Ttl] SOA PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL
Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/RecordAdd | Required. Adds or modifies a resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace for which the SOA record is added. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | Specifies that this resource record is able to be aged and scavenged. If this parameter is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time-To-Live (TTL) setting for the resource record. (The default TTL is defined in SOA resource record).
SOA | Required. Specifies the type of resource record you are modifying.
PrimSvr | Required. Specifies the FQDN name of the server that is the primary source for information about the zone. For example, nameserver.place.example.microsoft.com.
Admin | Required. Specifies the name of the DNS administrator for the zone. For example, postmaster.nameserver.place.example.microsoft.com.
Serial#\ | Required. Specifies the version information for the zone.
Refresh | Required. Specifies the refresh interval for the zone. The standard setting is 3600 (one hour).
Retry | Required. Specifies the retry interval for the zone. The standard setting is 600 (ten minutes).
Expire | Required. Specifies the expire interval for the zone. The standard setting is 86400 (one day).
MinTTL | Required. Specifies the minimum Time-To-Live value. This is the length of time used by other DNS servers to determine how long to cache information for a record in the zone before expiring and discarding it. The standard setting is 3600 (one hour).

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

  • To modify any specific SOA resource record's values using dnscmd, you must specify all of the SOA values (PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL).
  • By default, the retry interval for each zone is set at 10 minutes. The retry interval is used to determine how often other DNS servers that load and host the zone are to retry a request for update of the zone each time the refresh interval occurs.
XOX

Related Topics


Adjust the expire interval for a zone

Microsoft Windows graphic

To adjust the expire interval for a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone and click Properties.
  3. On the General tab, verify that the zone type is either Primary or Active Directory–integrated.
  4. Click the Start of Authority (SOA) tab.
  5. In Expires after, click an interval in either minutes, hours, or days, and then type a number in the text box.
  6. Click OK to save the adjusted interval.

Notes

  • XOX
  • XOX
  • By default, the expire interval for each zone is set to 1 day. The expire interval is used by other DNS servers configured to load and host the zone to determine when zone data expires if not renewed.

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [/OpenAcl] [Ttl] SOA PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL
Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/RecordAdd | Required. Adds or modifies a resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace for which the SOA record is added. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | Specifies that this resource record is able to be aged and scavenged. If this parameter is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time-To-Live (TTL) setting for the resource record. (The default TTL is defined in SOA resource record).
SOA | Required. Specifies the type of resource record you are modifying.
PrimSvr | Required. Specifies the FQDN name of the server that is the primary source for information about the zone. For example, nameserver.place.example.microsoft.com.
Admin | Required. Specifies the name of the DNS administrator for the zone. For example, postmaster.nameserver.place.example.microsoft.com.
Serial#\ | Required. Specifies the version information for the zone.
Refresh | Required. Specifies the refresh interval for the zone. The standard setting is 3600 (one hour).
Retry | Required. Specifies the retry interval for the zone. The standard setting is 600 (ten minutes).
Expire | Required. Specifies the expire interval for the zone. The standard setting is 86400 (one day).
MinTTL | Required. Specifies the minimum Time-To-Live value. This is the length of time used by other DNS servers to determine how long to cache information for a record in the zone before expiring and discarding it. The standard setting is 3600 (one hour).

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

  • To modify any specific SOA resource record's values using dnscmd, you must specify all of the SOA values (PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL).
XOX

Related Topics


Modify security for a directory-integrated zone

Microsoft Windows graphic

To modify security for a directory-integrated zone

  1. Open DNS.
  2. In the console tree, click the applicable zone.

    Where?

    • DNS
    • applicable DNS server
    • Forward Lookup Zones (or Reverse Lookup Zones)
    • applicable zone
  3. On the Action menu, click Properties.
  4. On the General tab, verify that the zone type is Active Directory–integrated.
  5. On the Security tab, modify the list of member users or groups that are allowed to securely update the applicable zone and reset their permissions as needed.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Secure dynamic updates are only supported for zones stored in Active Directory.
  • The security settings determine who can administer the zone, but do not affect dynamic updates to the zone. To apply security settings for dynamic updates, see Related Topics.
  • XOX

Related Topics


Manage resource records

  • Add a host (A) resource record to a zone
  • Add a mail exchanger (MX) resource record to a zone
  • Add an alias (CNAME) resource record to a zone
  • Add a new domain to a zone
  • Add a pointer (PTR) resource record to a reverse zone
  • Add a resource record to a zone
  • Modify an existing resource record in a zone
  • Delete a resource record from a zone
  • View unsupported resource records in a zone
  • Modify security for a resource record


Add a host (A) resource record to a zone

Microsoft Windows graphic

To add a host (A) resource record to a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable forward lookup zone and click New Host.
  3. In the Name text box, type the DNS computer name for the new host.
  4. In the IP address text box, type the IP address for the new host.
  5. As an option, select the Create associated pointer (PTR) record check box to create an additional pointer record in a reverse zone for this host, based on the information you entered in Name and IP address.
  6. Click Add Host to add the new host record to the zone.

Notes

  • XOX
  • XOX
  • PTR resource records created automatically when adding an A resource record to a zone will be deleted automatically if the corresponding A resource record is deleted.

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [/OpenAcl] [Ttl] A IPAddress
Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/RecordAdd | Required. Adds a new resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | Specifies that this resource record is able to be aged and scavenged. If this command is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time-To-Live (TTL) setting for the resource record. (The default TTL is defined in SOA resource record).
A | Required. Specifies the resource record type of the record you are adding.
IPAddress | Required. The IP address for the host.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

  • PTR resource records are deleted automatically if the corresponding A resource record is deleted.
XOX

Related Topics


Add a mail exchanger (MX) resource record to a zone

Microsoft Windows graphic

To add a mail exchanger (MX) resource record to a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable forward lookup zone and click New Mail Exchanger.
  3. In the Host or domain text box, type the domain name for which this record is to be used to deliver mail.
  4. In the Mail server text box, type the DNS host computer name of the mail exchanger or mail server host that delivers mail for the specified domain name.

    As an option, you can click Browse to view the DNS namespace for mail exchanger hosts in this domain that have host (A) records already defined.

  5. Adjust the Mail server priority as needed for this zone.
  6. Click OK to add the new record to the zone.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [Ttl] MX Preference MXServerName
Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/RecordAdd | Adds a new resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone in which you will add the new MX resource record.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | Specifies that this resource record is able to be aged and scavenged. If this command is used, this resource record is able to be aged and scavenged. If this command is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time-To-Live setting for the resource record.
MX | Required. Specifies the MX resource record type for the record you are adding.
Preference | Required. Specifies a numeric value (between 0 and 65535) that indicates the mail exchange server's priority with respect to the other mail exchange servers. Lower numbers are given greater preference.
MXServerName | Required. Specifies the fully qualified domain name (FQDN) for a mail exchanger. The value entered here must resolve to a corresponding host (A) resource record in this zone.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

XOX

Related Topics


Add an alias (CNAME) resource record to a zone

Microsoft Windows graphic

To add an alias (CNAME) resource record to a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable forward lookup zone, and then click New Alias.

  3. In the Alias name text box, type the alias name.

  4. In the Fully qualified domain name (FQDN) for target host text box, type the fully qualified domain name of the DNS host computer for which this alias is to be used.

    5. As an option, you can click Browse to search the DNS namespace for hosts in this domain that have host (A) records already defined.

  5. Click OK to add the new record to the zone.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [/OpenAcl] [Ttl] CNAME HostName|DomainName
Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/RecordAdd | Required. Specifies the command to add a new resource record.
ZoneName | Required. Specifies the name of the zone where this CNAME resource record will be added.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | Specifies that this resource record is aged and scavenged. If this parameter is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time-To-Live (TTL) setting for the resource record. (The default TTL is defined in SOA resource record).
CNAME | Required. Specifies the resource record type of the record you are adding.
HostName|DomainName | Required. Specifies the FQDN of any valid DNS host or domain name in the namespace. For FQDN's, a trailing period (.) is used to fully qualify the name.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

XOX

Related Topics


Add a new domain to a zone

Microsoft Windows graphic

To add a new domain to a zone

  1. Open DNS.
  2. In the console tree, click the applicable zone.

    Where?

    • DNS
    • applicable DNS server
    • Forward Lookup Zones (or Reverse Lookup Zones)
    • applicable zone
  3. On the Action menu, click New Domain, and then type the name of the new domain without using periods.
  4. Click OK to add the new domain to the zone.

Notes

  • XOX
  • XOX

Related Topics


Add a pointer (PTR) resource record to a reverse zone

Microsoft Windows graphic

To add a pointer (PTR) resource record to a reverse zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable reverse lookup zone.
  3. On the Action menu, click New Pointer.
  4. In the Host IP number text box, type the host IP address octet number.
  5. In the Host name text box, type the fully qualified domain name for the DNS host computer for which this pointer record is to be used to provide reverse lookup (address-to-name resolution).

    6. As an option, you can click Browse to search the DNS namespace for hosts in this domain that have host (A) records already defined.

  6. Click OK to add the new record to the zone.

Notes

  • XOX
  • XOX
  • When creating a new A resource record, there is an option to create an associated PTR resource record automatically. PTR resource records created automatically when adding an A resource record to a zone will be deleted automatically if the corresponding A resource record is deleted.

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [/OpenAcl] [Ttl] PTR HostName|DomainName
Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/RecordAdd | Required. Adds a new resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | Specifies that this resource record is able to be aged and scavenged. If this command is used, this resource record is able to be aged and scavenged. If this command is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time-To-Live setting for the resource record.
PTR | Required. Specifies the resource record type.
HostName|DomainName | Required. Specifies the FQDN of a resource record located in the DNS namespace. The host you specify is used as the data for answering reverse lookups based on the address information specified by this pointer (PTR) resource record.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

  • PTR resource records are deleted automatically if the corresponding A resource record is deleted.
XOX

Related Topics


Add a resource record to a zone

Microsoft Windows graphic

To add a resource record to a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone and click Other New Records.
  3. In Select a resource record type list box, select the type of resource record you want to add.
  4. Click Create Record.
  5. In New Resource Record, enter the information needed to complete the resource record.
  6. After you specify all of the necessary information for the resource record, click OK to add the new record to the zone.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [/OpenAcl] [Ttl] RRType RRData
Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/RecordAdd | Required. Adds a new resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | Specifies that this resource record is able to be aged and scavenged. If this command is used, this resource record is able to be aged and scavenged. If this command is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
Ttl | Specifies the Time-To-Live setting for the resource record.
RRType RRData Required. Specifies the type of resource record to add, followed by the data to be contained in the resource record.
Resource record type | Resource record data
A | IPAddress
NS,CNAME,MB,MD,PTR,MF,MG,MR | HostName|DomainName
MX,RT,AFSDB | Preference ServerName
SRV | Priority Weight Port HostName
SOA | PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL
AAAA | Ipv6Address
TXT,X25,HINFO,ISDN | String [String]
MINFO,RP | MailboxName ErrMailboxName
WKS | Protocol IPAddress Service...
WINS | MapFlag LookupTimeout CacheTimeout IPAddress...
WINSR | MapFlag LookupTimeout CacheTimeout RstDomainName
IPAddress | Specifies a standard IP address. For example, 255.255.255.255.
ipv6Address | Specifies a standard IPv6 address. For example, 1:2:3:4:5:6:7:8.
Protocol | Specifies the transmission protocol: UDP or TCP.
Service | Specifies a standard service. For example, domain, smtp.
HostName|DomainName | Specifies the FQDN of a resource record located in the DNS namespace.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

XOX

Related Topics


Modify an existing resource record in a zone

Microsoft Windows graphic

To modify an existing resource record in a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable zone.
  3. In the details pane, right-click the resource record you want to modify, and then click Properties.
  4. In Properties, edit the properties that can be modified.

    If necessary, you can view and modify advanced resource record properties for the DNS console. To display advanced properties, on the View menu, click Advanced.

  5. Click OK when you have finished modifying the record.

Notes

  • XOX
  • XOX
  • When Advanced view options are enabled, you can modify additional settings for an existing resource record, such as its record-specific Time to Live (TTL).

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [/OpenAcl] [Ttl] RRType RRData
Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/RecordAdd | Required. Adds a new resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
RRType RRData Required. Specifies the type of resource record to add, followed by the data to be contained in the resource record.
Resource record type | Resource record data
A | IPAddress
NS,CNAME,MB,MD,PTR,MF,MG,MR | HostName|DomainName
MX,RT,AFSDB | Preference ServerName
SRV | Priority Weight Port HostName
SOA | PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL
AAAA | Ipv6Address
TXT,X25,HINFO,ISDN | String [String]
MINFO,RP | MailboxName ErrMailboxName
WKS | Protocol IPAddress Service...
WINS | MapFlag LookupTimeout CacheTimeout IPAddress...
WINSR | MapFlag LookupTimeout CacheTimeout RstDomainName
IPAddress | Specifies a standard IP address. For example, 255.255.255.255.
ipv6Address | Specifies a standard IPv6 address. For example, 1:2:3:4:5:6:7:8.
Protocol | Specifies the transmission protocol: UDP or TCP.
Service | Specifies a standard service. For example, domain, smtp.
HostName|DomainName | Specifies the FQDN of a resource record located in the DNS namespace.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

XOX

Related Topics


Delete a resource record from a zone

Microsoft Windows graphic

To delete a resource record from a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable zone.
  3. In the details pane, right-click the resource record you want to delete, and then click Delete.
  4. When you are asked to confirm that you want to delete the selected resource record, click OK.

Notes

  • XOX
  • XOX
  • PTR resource records are deleted automatically if the corresponding A resource record is deleted.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /RecordDelete ZoneName NodeName RRType RRData [/f]

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/RecordDelete | Required. Deletes a resource record.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
NodeName | Required. Specifies the FQDN of the node in the DNS namespace. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
RRType RRData Required. Specifies the type of resource record (RR) to add, followed by the data to be contained in the resource record.
Resource record type | Resource record data
A | IPAddress
NS,CNAME,MB,MD,PTR,MF,MG,MR | HostName|DomainName
MX,RT,AFSDB | Preference ServerName
SRV | Priority Weight Port HostName
SOA | PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL
AAAA | Ipv6Address
TXT,X25,HINFO,ISDN | String [String]
MINFO,RP | MailboxName ErrMailboxName
WKS | Protocol IPAddress Service...
WINS | MapFlag LookupTimeout CacheTimeout IPAddress...
WINSR | MapFlag LookupTimeout CacheTimeout RstDomainName
IPAddress | Specifies a standard IP address. For example, 255.255.255.255.
ipv6Address | Specifies a standard IPv6 address. For example, 1:2:3:4:5:6:7:8.
Protocol | Specifies the transmission protocol: UDP or TCP.
Service | Specifies a standard service. For example, domain, smtp.
HostName|DomainName | Specifies the FQDN of a resource record located in the DNS namespace.
/f | Specifies that the command is executed without asking for confirmation. If you omit this parameter, you are prompted to confirm the deletion of the resource record.

Important

  • If the parameter RRData is not specified, all resource records of the same type are deleted.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordDelete /help

  • If the variable RRData is not specified, all resource record types matching the previous criteria are deleted.
  • PTR resource records are deleted automatically if the corresponding A resource record is deleted.
XOX

Related Topics


View unsupported resource records in a zone

Microsoft Windows graphic

To view unsupported resource records in a zone

  1. Open DNS.
  2. In the console tree, click the applicable zone.
  3. In the details pane, right-click the record you want to view, then click Properties.
  4. In Properties, view properties specific to this record.
  5. When you have finished viewing the record, click OK.

Notes

  • XOX
  • XOX
  • The DNS console allows you to view unsupported resource records (RRs) in secondary zones that are obtained from other DNS server implementations, such as DNS servers running versions of BIND. These records are not used by DNS servers running Windows Server 2003 and cannot be managed through the DNS console. These types of records include legacy records, such as mail forwarder (MF) and mail domain (MD) resource records (RRs).

Related Topics


Modify security for a resource record

Microsoft Windows graphic

To modify security for a resource record

  1. Open DNS.
  2. In the console tree, click the applicable zone.
  3. In the details pane, click the record you want to view.
  4. On the Action menu, click Properties.
  5. On the Security tab, modify the list of member users or groups that are allowed to securely update the applicable record and reset their permissions as needed.

Notes

  • To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Secure dynamic updates are only supported or configurable for resource records in zones stored in Active Directory.
  • Security settings applied to resource records only affect dynamic updates. These security settings do not affect who may administer the zone where these resource records are located. For information on the security settings that affect who may administer a zone, see Related Topics.
  • Resource records with the same name share the same resource record security settings. The names of resource records are listed in the Name column of the DNS console.
  • XOX

Related Topics


Use aging and scavenging

  • Set aging/scavenging properties for the DNS server
  • Set aging/scavenging properties for a selected zone
  • Enable automatic scavenging of stale resource records
  • Start immediate scavenging of stale resource records
  • View when a zone can start scavenging stale records
  • Reset scavenging and aging properties for a specified resource record


Set aging/scavenging properties for the DNS server

Microsoft Windows graphic

To set aging/scavenging properties for the DNS server

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable DNS server, and then click Set Aging/Scavenging for all zones.
  3. Select the Scavenge stale resource records check box.
  4. Modify other aging and scavenging properties as needed.

Notes

  • XOX
  • XOX
  • Aging and scavenging properties configured by this procedure act as server defaults that apply only toward Active Directory–integrated zones. For standard primary zones, you must set the appropriate properties at the applicable zone.
  • Once you apply changes for server aging/scavenging settings, the DNS console prompts you to confirm. You then have the option to apply your changes to new Active Directory–integrated zones only. If needed, you can also apply your changes to existing Active Directory–integrated zones.
  • Regardless of whether the Scavenge stale resource records check box is selected as described in step 4, for standard primary zones, this feature is disabled unless manually enabled at the applicable zone.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /Config {/ScavengingInterval Value|/DefaultAgingState Value|/DefaultNoRefreshInterval Value|/DefaultRefreshInterval Value}

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/Config | Required. Specifies the configuration command.
/ScavengingInterval | Required. Sets the frequency by which the server will perform scavenging for all scavenging-enabled zones.
/DefaultAgingState | Required. Sets the default aging configuration for all zones on the server.
/DefaultNoRefreshInterval | Required. Sets the default No-refresh interval for scavenging-enabled zones.
/DefaultRefreshInterval | Sets the default Refresh interval for scavenging-enabled zones.
Value | For /ScavengingInterval, type a value in hours. The default is 168 (one week). For /DefaultAgingState, type 1 to enable aging for new zones when they are created. Type 0 to disable aging for new zones. For /DefaultNoRefreshInterval, type a value in hours. The default is 168 (one week). For /DefaultRefreshInterval, type a value in hours. The default is 168 (one week).

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /Config /help

XOX

Related Topics


Set aging/scavenging properties for a zone

Microsoft Windows graphic

To set aging/scavenging properties for a zone

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable zone, then click Properties.
  3. On the General tab, click Aging.
  4. Select the Scavenge stale resource records check box.
  5. Modify other aging and scavenging properties as needed.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName /Config {ZoneName|..AllZones} {/Aging Value|/RefreshInterval Value|/NoRefreshInterval Value}

Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/Config | Required. Specifies the configuration command.
ZoneName|..AllZones | Required. Specifies the name of the zone to which you want to set aging and scavenging. To apply the operation to all zones, use ..AllZones.
/Aging | Required. Enables aging for zones.
/RefreshInterval | Required. Specifies the Refresh interval for a scavenging-enabled zone.
/NoRefreshInterval | Required. Specifies the No-refresh interval for a scavenging-enabled zone.
Value | Required. For /Aging, type 1 to enable aging. Type 0 to disable aging. For /RefreshInterval, type a value in hours. The default setting is 168 hours (one week). For /NoRefreshInterval, type a value in seconds. The standard setting is 3600 (one hour).

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /Config /help

XOX

Related Topics


Enable automatic scavenging of stale resource records

Microsoft Windows graphic

To enable automatic scavenging of stale resource records

  1. Open DNS.
  2. In the console tree, right-click the applicable DNS server, then click Properties.
  3. Click the Advanced tab.
  4. Select the Enable automatic scavenging of stale records check box.
  5. To adjust the Scavenging period, select from the drop-down list an interval in either hours or days, and then type a number in the text box.

Notes

  • XOX
  • XOX

Related Topics


Start immediate scavenging of stale resource records

Microsoft Windows graphic

To start immediate scavenging of stale resource records

Using the Windows interface

  1. Open DNS.
  2. In the console tree, right-click the applicable DNS server, then click Scavenge Stale Resource Records.
  3. When asked to confirm that you want to scavenge all stale resource records on the server, click OK.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd ServerName //StartScavenging

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
//StartScavenging | Required. Initiates resource record scavenging.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /StartScavenging /help

XOX

Related Topics


View when a zone can start scavenging stale records

Microsoft Windows graphic

To view when a zone can start scavenging stale records

Using the Windows interface

  1. Open DNS.
  2. On the View menu, click Advanced.
  3. Right-click the applicable zone, then click Properties.
  4. On the General tab, click Aging.
  5. Under Refresh interval, view when the zone is first eligible to be scavenged for stale resource records.

Notes

  • XOX
  • XOX
  • The start scavenging date and time stamp are used to determine when zone scavenging starts. For more information, see Related Topics.
  • After the start scavenging date and time stamp are reached, scavenging can occur only if the Scavenge stale resource records check box is selected. If the check box is cleared, scavenging for the zone cannot be performed.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dnscmd Server /ZoneInfo ZoneName RefreshInterval

Value | Description
dnscmd | Specifies the name of the command-line tool.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZoneInfo | Required. Displays configuration information.
ZoneName | Required. Specifies the fully qualified domain name (FQDN) of the zone.
RefreshInterval | Required. Specifies the configuration property that displays when the zone is first eligible to be scavenged for stale resource records. The output value is in hours. The default setting is 168 hours (one week).

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /ZoneInfo /help

XOX

Related Topics


Reset scavenging and aging properties for a specified resource record

Microsoft Windows graphic

To reset scavenging and aging properties for a specified resource record

Using the Windows interface

  1. Open DNS.
  2. In the console tree, click the applicable zone.
  3. In the details pane, double-click the resource record for which you want to reset scavenging and aging properties.
  4. Depending on the how the resource record was originally added to the zone, do one of the following:
    • If the record was added dynamically using dynamic update, you can clear the Delete this record when it becomes stale check box to prevent its aging or potential removal during the scavenging process. If dynamic updates to this record continue to occur, the DNS server will always reset this check box so that the dynamically updated record can be deleted.
    • If you added the record statically, you can select Delete this record when it becomes stale check box to permit its aging or potential removal during the scavenging process.

Notes

  • XOX
  • XOX
  • This procedure is only necessary for resource records that are dynamically registered. For records that you manually add to a zone, a time stamp value of zero always applies to the record, excluding it from the scavenging process.
  • Scavenging and aging properties for NS and SOA resource records are reset in the properties for the zone, not the properties for the resource record.

Using a command line

  1. Open Command Prompt.
  2. Type: dnscmd ServerName /Config {ZoneName|..AllZones} /ScavengingInterval Value
Value | Description
dnscmd | Specifies the name of the command-line program.
ServerName | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/Config | Required. Specifies the configuration command.
ZoneName|..AllZones | Required. Specifies the fully qualified domain name (FQDN) of the zone. To configure all zones hosted on the specified DNS server to allow dynamic updates, type ..AllZones.
/ScavengingInterval | Required. Sets the scavenging interval.
Value | Required. The new value for the scavenging interval, specified in hours. The default is 168 (one week).

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dnscmd /RecordAdd /help

XOX

Related Topics


Concepts

This section provides general background information about Domain Name System (DNS) and the DNS Server service, as well as details about supporting software provided for DNS clients running under Microsoft operating systems.

  • DNS overview
  • Understanding DNS
  • Deploying DNS
  • Administering DNS
  • Resources


DNS overview

This section covers:

  • DNS defined
  • DNS tools
  • Server features
  • Client features
  • Security information for DNS
  • New features for DNS


DNS defined

DNS is an abbreviation for Domain Name System, a system for naming computers and network services that is organized into a hierarchy of domains. DNS naming is used in TCP/IP networks, such as the Internet, to locate computers and services through user-friendly names. When a user enters a DNS name in an application, DNS services can resolve the name to other information associated with the name, such as an IP address.

For example, most users prefer a friendly name such as example.microsoft.com to locate a computer such as a mail or Web server on a network. A friendly name can be easier to learn and remember. However, computers communicate over a network by using numeric addresses. To make the use of network resources easier, name systems such as DNS provide a way to map the user-friendly name for a computer or service to its numeric address.

The following figure shows a basic use of DNS, which is finding the IP address of a computer based on its name.

Example of DNS forward lookup

In this example, a client computer queries a DNS server, asking for the IP address of a computer configured to use host-a.example.microsoft.com as its DNS domain name. Because the DNS server is able to answer the query based on its local database, it replies with an answer containing the requested information, which is a host (A) resource record that contains the IP address information for host-a.example.microsoft.com.

The example shows a simple DNS query between a single client and DNS server. In practice, DNS queries can be more involved than this and include additional steps not shown here. For more information, see How DNS query works.

Note

  • For additional background information about other DNS concepts, see Understanding DNS.


DNS tools

There are a number of utilities for administering, monitoring, and troubleshooting both DNS servers and clients. These utilities include:

  • The DNS console, which is part of Administrative Tools.
  • Command-line utilities, such as Nslookup, which can be used to troubleshoot DNS problems.
  • Logging features, such as the DNS server log, which can be viewed using the DNS console or Event Viewer. File-based logs can also be used temporarily as an advanced debugging option to log and trace selected service events.
  • Performance monitoring utilities, such as statistical counters to measure and monitor DNS server activity with System Monitor.
  • Windows Management Instrumentation (WMI), a standard technology for accessing management information in an enterprise environment.
  • Platform Software Developer Kit (SDK).

The DNS console

The primary tool that you use to manage DNS servers is the DNS console, which is located in the Administrative Tools folder in the Start menu's Programs folder. The DNS console can be used on its own or as a Microsoft Management Console (MMC) , further integrating DNS administration into your total network management.

The DNS console can only be used after DNS in installed on the server. You can use the DNS console to perform these basic administrative server tasks:

  1. Performing initial configuration of a new DNS server.
  2. Connecting to and managing a local DNS server on the same computer, or remote DNS servers on other computers.
  3. Adding and removing forward and reverse lookup zones as needed.
  4. Adding, removing, and updating resource records in zones.
  5. Modifying how zones are stored and replicated between servers.
  6. Modifying how servers process queries and handle dynamic updates.
  7. Modifying security for specific zones or resource records.

In addition, you can also use the DNS console to perform the following tasks:

  • Perform maintenance on the server. You can start, stop, pause, or resume the server, or manually update server data files.
  • Monitor the contents of the server cache and, as needed, clear it.
  • Tune advanced server options.
  • Configure and perform aging and scavenging of stale resource records stored by the server.

In addition, you can also operate the DNS console from a workstation to remotely administer DNS servers. For more information, see Windows Server 2003 Administration Tools Pack .

Important

  • The DNS console can only be used to manage DNS servers running Microsoft® Windows® and cannot be used to manage other DNS servers, such as BIND.

Notes

  • The DNS console provides new ways to perform familiar DNS administrative tasks previously performed in Microsoft® Windows® NT Server 4.0 using DNS Manager. For more information, see New ways to do familiar tasks.
  • To use the DNS console from another non-server computer, such as one running XOX, you must install the Windows Server 2003 Administration Tools Pack
  • For information on installing DNS, see To install a DNS server.

Command-line utilities

There are several command-line utilities you can use to manage and troubleshoot DNS servers and clients. The following table describes each of these utilities, which can be run either by typing them at a command prompt or by entering them in batch files for scripted use.

Command | Description
Nslookup | Used to perform query testing of the DNS domain namespace. For more information, see Nslookup.
Dnscmd | A command-line interface for managing DNS servers. This utility is useful in scripting batch files to help automate routine DNS management tasks, or to perform simple unattended setup and configuration of new DNS servers on your network. For more information, see Server administration using Dnscmd.
Ipconfig | This command is used to view and modify IP configuration details used by the computer. Additional command-line options are included with this utility to provide help in troubleshooting and supporting DNS clients. For more information, see To flush and reset a client resolver cache using the ipconfig command or To renew DNS client registration using the ipconfig command.

For information about other command-line utilities, see Command-Line Reference. For more information about manageability, see Management Strategies and Tools.

Event monitoring utilities

The Windows® Server 2003 family includes two options for monitoring DNS servers:

  • Default logging of DNS server event messages to the DNS server log.

    DNS server event messages are separated and kept in their own system event log, the DNS server log, which can be viewed using the DNS console or Event Viewer. For more information, see To view the DNS server system event log.

    The DNS server log contains events logged by the DNS Server service. For example, when the DNS server starts or stops, a corresponding event message is written to this log. Most additional critical DNS Server service events are also logged here, such as when the server starts but cannot locate initializing data, such as zones or boot information stored in the registry or (in some cases) Active Directory.

    The event types logged by DNS servers can be changed using the DNS console. For more information, see DNS server log reference.

    You can use Event Viewer to view and monitor client-related DNS events. These appear in the System log and are written by the DNS Client service at any computers running Windows (all versions). For more information, see Event Viewer.

  • Optional debug options for trace logging to a text file on the DNS server computer.

    You can also use the DNS console to selectively enable additional debug logging options for temporary trace logging to a text-based file of DNS server activity. The file created and used for this feature, Dns.log, is stored in the systemroot\System32\Dns folder.

    For more information, see Using server debug logging options.

Performance monitoring utilities

Performance monitoring for DNS servers can be done using additional service-specific counters that measure DNS server performance. These counters are accessible through System Monitor, which is provided in the Performance console.

When using System Monitor, you can create charts and graphs of server performance trends over time for any of your DNS servers. These can be further studied and analyzed to determine if additional server tuning is needed.

By measuring and reviewing server metrics over a period of time, it is possible to determine performance benchmarks and decide if further adjustments can be made to optimize the system. For more information, see Monitoring DNS server performance.

Windows Management Instrumentation (WMI)

WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI uses the Common Information Model (CIM) industry standard to represent systems, applications, networks, devices, and other managed components in an enterprise environment. For more information about Windows Management Instrumentation, see the Microsoft Platform SDK Web site. (http://msdn.microsoft.com/)

Platform Software Developer Kit (SDK)

Computers running a product in the Windows Server 2003 family provide functions that enable application programmers to use DNS, such as programmatically making DNS queries, comparing records, and looking up names.

Programmable DNS components are designed for use by C/C++ programmers. Familiarity with networking and with DNS is required. Programmers should be familiar with the IP protocol suite, as well as the DNS protocol and how DNS operates.

Notes

  • For more information about manageability, see Management Strategies and Tools.


Server features

The Domain Name System (DNS) Server service provides the following:

  • An RFC-compliant DNS server

    DNS is an open protocol and is standardized by a set of Request for Comments (RFCs). Microsoft supports and complies with these standard specifications.

    For more information, see DNS RFCs.

  • Interoperability with other DNS server implementations

    Because the DNS Server service is RFC-compliant and can use standard DNS data file and resource record formats, it can successfully work with most other DNS server implementations, such as those that use the Berkeley Internet Name Domain (BIND) software.

    For more information, see Interoperability issues.

  • Support for Active Directory

    DNS is required for support of the Active Directory® directory service. If you install Active Directory on a server, you can automatically install and configure a DNS server if a DNS server that meets the Active Directory requirements cannot be located.

    First, in the Active Directory Installation Wizard, you specify the DNS name of the Active Directory domain for which you are promoting the server to become a domain controller. Later in the installation process, the wizard tests for the following:

    1. Based on its TCP/IP client configuration, it checks to see whether a preferred DNS server is configured for its use.
    2. If a preferred DNS server is available, it queries to find the primary authoritative server for the DNS name of the Active Directory domain you specified earlier in the wizard.
    3. It then tests to see whether the authoritative primary server can support and accept dynamic updates as described in the dynamic update protocol (RFC 2136).
    4. If, at this point in the process, a supporting DNS server cannot be located to accept updates for the specified DNS domain name you are using with Active Directory, you are provided with the option to install the DNS Server service locally.
    5. If you choose to install the DNS Server service locally, the IP address for the current preferred DNS server is used to configure a forwarder on the local DNS server. This configuration maintains any existing resolution to an Internet Service Provider (ISP).

    In general, the use of the Windows Server 2003 DNS Server service is strongly recommended for the best possible integration and support of Active Directory and enhanced DNS server features. You can, however, use another type of DNS server to support Active Directory deployment.

    When using other types of DNS servers, consider additional issues related to DNS interoperability. For more information, see Supporting Active Directory with other DNS server implementations.

    Note

    • XOX
  • Enhancements to DNS zone storage in Active Directory

    • DNS zones can be stored in the domain or application directory partitions of Active Directory. A partition is a data structure within Active Directory used to distinguish data for different replication purposes. You can specify in which Active Directory partition to store the zone and, consequently, the set of domain controllers between which that zone's data will be replicated.

    For more information, see DNS zone replication in Active Directory.

    Note

    • XOX
  • Conditional forwarders

    • The DNS Server service extends a standard forwarder configuration with conditional forwarders. A conditional forwarder is a DNS server on a network that is used to forward DNS queries according to the DNS domain name in the query. For example, a DNS server can be configured to forward all the queries it receives for names ending with widgets.example.com to the IP address of a specific DNS server or to the IP addresses of multiple DNS servers.

    For more information, see Understanding forwarders.

  • Stub zones

    • DNS supports a new zone type called a stub zone. A stub zone is a copy of a zone that contains only those resource records necessary to identify the authoritative DNS servers for that zone. A stub zone is used to keep a DNS server hosting a parent zone aware of the authoritative DNS servers for its child zone and thereby maintain DNS name resolution efficiency.

    For more information, see Understanding stub zones.

  • Enhanced DNS security features

    • DNS provides enhanced security administration for the DNS Server service, the DNS Client service, and DNS data. For more information, see Security information for DNS.

  • Integration with other Microsoft networking services

    The DNS Server service offers integration with other services and contains features beyond those specified in the RFCs. These include integration with Active Directory, WINS, and DHCP services.

    For more information, see Active Directory integration; WINS lookup integration; Dynamic update.

  • Improved ease of administration

    The DNS console offers an improved graphical user interface for managing the DNS Server service. Also, there are several configuration wizards for performing common server administration tasks. In addition to the DNS console, other tools are provided to help you better manage and support DNS servers and clients on your network.

    For more information, see DNS tools.

  • RFC-compliant dynamic update protocol support

    The DNS Server service allows clients to dynamically update resource records, based on the dynamic update protocol (RFC 2136). This improves DNS administration by reducing the time needed to manually manage these records. Computers running the DNS Client service can dynamically register their DNS names and IP addresses.

    For more information, see Dynamic update.

  • Support for incremental zone transfer between servers

    Zone transfers are used between DNS servers to replicate information about a portion of the DNS namespace. Incremental zone transfer is used to replicate only the changed portions of a zone, conserving network bandwidth.

    For more information, see Understanding zones and zone transfer.

  • Support for new resource record types

    The DNS Server service includes support for several new resource record (RR) types. These types, which include the service location (SRV) and ATM address (ATMA) RRs, expand the possibilities for using DNS as a names database service.

    For more information, see Resource records reference.


Client features

The Domain Name System (DNS) Client service is used to resolve DNS domain names and implements the following features:

  • System-wide caching

    Resource records (RRs) from query responses are added to the client cache as applications query DNS servers. This information is then cached for a set Time to Live (TTL) and can be used again to answer subsequent queries.

  • RFC-compliant negative caching support

    In addition to caching positive query responses from DNS servers (which contain resource record information in the answered reply), the DNS Client service also caches negative query responses. A negative response results when a resource record for the queried name does not exist.

    Negative caching prevents the repeating of additional queries for names that do not exist, which can adversely affect client system performance. Any query information negatively cached is kept for a shorter period of time than is used for positive query responses; by default, no more than 5 minutes. This avoids continued negative caching of stale information if the records later become available.

    Negative caching is a new DNS standard specification defined in RFC 2308. For more information, refer to this RFC. For more information on obtaining RFCs, see TCP/IP RFCs.

  • Avoidance of unresponsive DNS servers

    The DNS Client service uses a server search list, ordered by preference. This list includes all preferred and alternate DNS servers configured for each of the active network connections on the system.

    The list is arranged based on the following criteria:

    1. Preferred DNS servers are given first priority.
    2. If no preferred DNS servers are available, then alternate DNS servers are used.
    3. Unresponsive servers are removed temporarily from these lists.

Important

  • The DHCP Client service initiates dynamic registration for client DNS names. For more information, see Dynamic update or Using DNS servers with DHCP.


Security information for DNS

Domain Name System (DNS) was originally designed as an open protocol and is therefore vulnerable to attackers. Windows Server 2003 DNS has improved the ability to prevent an attack on your DNS infrastructure through the addition of security features. Before considering which of the security features to use, you should be aware of the common threats to DNS security and the level of DNS security in your organization.

DNS security threats

The following are the typical ways in which your DNS infrastructure can be threatened by attackers:

  • Footprinting is the process by which DNS zone data is obtained by an attacker to provide the attacker with the DNS domain names, computer names, and IP addresses for sensitive network resources. An attacker commonly begins an attack by using this DNS data to diagram, or footprint, a network. DNS domain and computer names usually indicate the function or location of a domain or computer in order to help users remember and identify domains and computers more easily. An attacker takes advantage of the same DNS principle to learn the function or location of domains and computers in the network.
  • Denial-of-service attack is when an attacker attempts to deny the availability of network services by flooding one or more DNS servers in the network with recursive queries. As a DNS server is flooded with queries, its CPU usage will eventually reach its maximum and the DNS Server service will become unavailable. Without a fully operating DNS server on the network, network services that use DNS will become unavailable to network users.
  • Data modification is an attempt by an attacker (that has footprinted a network using DNS) to use valid IP addresses in IP packets the attacker has created, thereby giving these packets the appearance of coming from a valid IP address in the network. This is commonly called IP spoofing. With a valid IP address (an IP address within the IP address range of a subnet), the attacker can gain access to the network and destroy data or conduct other attacks.
  • Redirection is when an attacker is able to redirect queries for DNS names to servers under the control of the attacker. One method of redirection involves the attempt to pollute the DNS cache of a DNS server with erroneous DNS data that may direct future queries to servers under the control of the attacker. For example, if a query were originally made for example.microsoft.com and a referral answer provided a record for a name outside of the microsoft.com domain, such as malicious-user.com, then the DNS server would use the cached data for malicious-user.com to resolve a query for that name. Redirection can be accomplished whenever an attacker has writable access to DNS data, such as with insecure dynamic updates.

Mitigating DNS security threats

DNS can be configured to mitigate the common DNS security issues discussed above. The following table lists five main areas on which to concentrate when determining your DNS security.

DNS security area | Description
DNS namespace | Incorporate DNS security into your DNS namespace design. For more information, see Securing DNS deployment.
DNS Server service | Review the default DNS Server service security settings and apply Active Directory security features when the DNS Server service is running on a domain controller. For more information, see Securing the DNS Server service.
DNS zones | Review the default DNS zone security settings and apply secure dynamic updates and Active Directory security features when the DNS zone is hosted on a domain controller. For more information, see Securing DNS zones.
DNS resource records | Review the default DNS resource record (RR) security settings and apply Active Directory security features when the DNS resource records are hosted on a domain controller. For more information, see Securing DNS resource records.
DNS clients | Control the DNS server IP addresses used by DNS clients. For more information, see Securing DNS clients.

Three levels of DNS security

The following three levels of DNS security will help you understand your current DNS configuration and enable you to increase the DNS security of your organization.

Low-level security

Low-level security is a standard DNS deployment without any security precautions configured. Only deploy this level of DNS security in network environments where there is no concern for the integrity of your DNS data or in a private network where there is no threat of external connectivity.

  • The DNS infrastructure of your organization is fully exposed to the Internet.
  • Standard DNS resolution is performed by all DNS servers in your network.
  • All DNS servers are configured with root hints pointing to the root servers for the Internet.
  • All DNS servers permit zone transfers to any server.
  • All DNS servers are configured to listen on all of their IP addresses.
  • Cache pollution prevention is disabled on all DNS servers.
  • Dynamic update is allowed for all DNS zones.
  • User Datagram Protocol (UDP) and Transmission Control Protocol/Internet Protocol (TCP/IP) port 53 is open on the firewall for your network for both source and destination addresses.

Medium-level security

Medium-level security uses the DNS security features available without running DNS servers on domain controllers and storing DNS zones in Active Directory.

  • The DNS infrastructure of your organization has limited exposure to the Internet.
  • All DNS servers are configured to use forwarders to point to a specific list of internal DNS servers when they cannot resolve names locally.
  • All DNS servers limit zone transfers to servers listed in the name server (NS) resource records in their zones.
  • DNS servers are configured to listen on specified IP addresses.
  • Cache pollution prevention is enabled on all DNS servers.
  • Dynamic update is not allowed for any DNS zones.
  • Internal DNS servers communicate with external DNS servers through the firewall with a limited list of source and destination addresses allowed.
  • External DNS servers in front of your firewall are configured with root hints pointing to the root servers for the Internet.
  • All Internet name resolution is performed using proxy servers and gateways.

High-level security

High-level security uses the same configuration as medium-level security and also uses the security features available when the DNS Server service is running on a domain controller and DNS zones are stored in Active Directory. In addition, high-level security completely eliminates DNS communication with the Internet. This is not a typical configuration, but it is recommended whenever Internet connectivity is not required.

  • The DNS infrastructure of your organization has no Internet communication by internal DNS servers.
  • Your network uses an internal DNS root and namespace, where all authority for DNS zones is internal.
  • DNS servers that are configured with forwarders use internal DNS server IP addresses only.
  • All DNS servers limit zone transfers to specified IP addresses.
  • DNS servers are configured to listen on specified IP addresses.
  • Cache pollution prevention is enabled on all DNS servers.
  • Internal DNS servers are configured with root hints pointing to the internal DNS servers hosting the root zone for your internal namespace.
  • All DNS servers are running on domain controllers. A discretionary access control list (DACL) is configured on the DNS Server service to only allow specific individuals to perform administrative tasks on the DNS server.
  • All DNS zones are stored in Active Directory. A DACL is configured to only allow specific individuals to create, delete, or modify DNS zones.
  • DACLs are configured on DNS resource records to only allow specific individuals to create, delete, or modify DNS data.
  • Secure dynamic update is configured for DNS zones, except the top-level and root zones, which do not allow dynamic updates at all.


New features for DNS

The following new DNS features and feature enhancements are available with the Microsoft® Windows® Server 2003 family.

  • Conditional forwarders

    Forward DNS queries according to the DNS domain name in the query using conditional forwarders. For example, a DNS server can be configured to forward all the queries it receives for names ending with widgets.example.com to the IP address of a specific DNS server or to the IP addresses of multiple DNS servers.

    For more information, see Conditional forwarders.

  • Stub zones

    Using stub zones, keep a DNS server hosting a parent zone aware of the authoritative DNS servers for its child zone and, thereby, maintain DNS name resolution efficiency.

    For more information, see Understanding stub zones.

  • DNS zone replication in Active Directory

    Choose from four default replication options for Active Directory–integrated DNS zone data.

    For more information, see DNS zone replication in Active Directory.

  • Enhanced DNS security features

    DNS provides greater granularity in its security administration for the DNS Server service, the DNS Client service, and DNS data.

    For more information, see Security information for DNS.

  • Round robin all resource record (RR) types

    By default, the DNS Server service will perform round-robin rotation for all resource record (RR) types.

    For more information, see Restricting round-robin rotation for all RR types.

  • Enhanced debug logging

    Use the enhanced DNS Server service debug logging settings to troubleshoot DNS problems.

    For more information, see Using server debug logging options.

  • DNSSEC

    DNS provides basic support of DNS Security Extensions (DNSSEC) protocol as defined in RFC 2535.

    For more information, see Using DNS Security Extensions (DNSSEC).

  • EDNS0

    Enable DNS requestors to advertise the size of their UDP packets and facilitate the transfer of packets larger than 512 octets, the original DNS restriction for UDP packet size (RFC 1035).

    For more information, see Using Extension Mechanisms for DNS (EDNS0).

  • Control automatic NS resource record registration on a server and a zone basis

    For more information, see To restrict NS resource record registration and To allow NS resource record creation for specific domain controllers.


Understanding DNS

This section covers:

  • DNS domain names
  • How DNS query works
  • Understanding zones and zone transfer
  • Reverse lookup
  • Understanding forwarders
  • Understanding stub zones
  • Dynamic update
  • Active Directory integration
  • DNS zone replication in Active Directory
  • DNS requirements for installing Active Directory
  • DNS requirements for joining an Active Directory domain
  • Understanding aging and scavenging
  • Unicode character support
  • WINS lookup integration


DNS domain names

Domain Name System (DNS) was originally defined in Request for Comments (RFCs) 1034 and 1035. These documents specify elements common to all implementations of DNS-related software, including:

  • A DNS domain namespace, which specifies a structured hierarchy of domains used to organize names.
  • Resource records, which map DNS domain names to a specific type of resource information for use when the name is registered or resolved in the namespace.
  • DNS servers, which store and answer name queries for resource records.
  • DNS clients, also known as resolvers, which query servers to look up and resolve names to a type of resource record specified in the query.

For more information about Requests for Comments (RFCs), see DNS RFCs.

Understanding the DNS domain namespace

The DNS domain namespace, as shown in the following figure, is based on the concept of a tree of named domains. Each level of the tree can represent either a branch or a leaf of the tree. A branch is a level where more than one name is used to identify a collection of named resources. A leaf represents a single name used once at that level to indicate a specific resource.

DNS Domain namespace

The previous figure shows how Microsoft is assigned authority by the Internet root servers for its own part of the DNS domain namespace tree on the Internet. DNS clients and servers use queries as the fundamental method of resolving names in the tree to specific types of resource information. This information is provided by DNS servers in query responses to DNS clients, who then extract the information and pass it to a requesting program for resolving the queried name.

In the process of resolving a name, keep in mind that DNS servers often function as DNS clients, querying other servers in order to fully resolve a queried name. For more information, see How DNS query works.

How the DNS domain namespace is organized

Any DNS domain name used in the tree is technically a domain. Most DNS discussions, however, identify names in one of five ways, based on the level and the way a name is commonly used. For example, the DNS domain name registered to Microsoft (microsoft.com.) is known as a second-level domain. This is because the name has two parts (known as labels) that indicate it is located two levels below the root or top of the tree. Most DNS domain names have two or more labels, each of which indicates a new level in the tree. Periods are used in names to separate labels.

In addition to second-level domains, other terms used to describe DNS domain names by their function in the namespace are described in the following table.

Name type | Description | Example
The domain root | This is the top of the tree, representing an unnamed level; it is sometimes shown as two empty quotation marks (""), indicating a null value. When used in a DNS domain name, it is stated by a trailing period (.) to designate that the name is located at the root or highest level of the domain hierarchy. In this instance, the DNS domain name is considered to be complete and points to an exact location in the tree of names. Names stated this way are called fully qualified domain names (FQDNs). | A single period (.) or a period used at the end of a name, such as "example.microsoft.com.".
Top-level domain | A name of two or three letters used to indicate a country/region or the type of organization using a name. For more information, see Top-level domains. | ".com", which indicates a name registered to a business for commercial use on the Internet.
Second-level domain | Variable-length names registered to an individual or organization for use on the Internet. These names are always based upon an appropriate top-level domain, depending on the type of organization or geographic location where a name is used. | "microsoft.com.", which is the second-level domain name registered to Microsoft by the Internet DNS domain name registrar.
Subdomain | Additional names that an organization can create that are derived from the registered second-level domain name. These include names added to grow the DNS tree of names in an organization and divide it into departments or geographic locations. | "example.microsoft.com.", which is a fictitious subdomain assigned by Microsoft for use in documentation example names.
Host or resource name | Names that represent a leaf in the DNS tree of names and identify a specific resource. Typically, the leftmost label of a DNS domain name identifies a specific computer on the network. For example, if a name at this level is used in a host (A) RR, it is used to look up the IP address of computer based on its host name. | "host-a.example.microsoft.com.", where the first label ("host-a") is the DNS host name for a specific computer on the network.

Interpreting a DNS domain name

DNS has a method of noting and interpreting the fully qualified path to a DNS domain name similar to the way full paths to files or directories are noted or displayed at a command prompt.

For example, a directory tree path helps point to the exact location of a file stored on your computer. For Windows computers, the back slash (\) indicates each new directory that leads to the exact location of a file. For DNS, the equivalent is a period (.) indicating each new domain level used in a name.

For example, for a file called Services, the full path to this file as displayed at a Windows command prompt would be:

C:\Windows\System32\Drivers\Etc\Services

To interpret the full path of the file, the name is read in a left-to-right direction from the highest or most general piece of information (drive C, the drive where the file is stored) to its most specific information, the file name "Services". This example shows five separate levels of hierarchy that lead toward the location of the Services file on drive C:

  1. The root folder for drive C (C:\).
  2. The system root folder where Windows is installed (Windows).
  3. A system folder where system components are stored (System32).
  4. A subfolder where system device drivers are stored (Drivers).
  5. A subfolder where miscellaneous files used by system and network device drivers are stored (Etc).

For DNS, an example of a domain name with multiple levels is the following, a fully qualified domain name (FQDN):

host-a.example.microsoft.com.

Unlike the file name example, a DNS FQDN, when read from left to right, moves from its most specific information (the DNS name for a computer called "host-a") to its highest or most general piece of information (the trailing period (.) that indicates the root of the DNS name tree). This example shows the four separate DNS domain levels that lead away from the specific host location of "host-a":

  1. The "example" domain, which corresponds to a subdomain where the computer name "host-a" is registered for use.
  2. The "microsoft" domain, which corresponds to the parent domain that roots the "example" subdomain.
  3. The "com" domain, which corresponds to the top-level domain designated for use by business or commercial organizations that roots the "microsoft" domain.
  4. The trailing period (.), which is a standard separator character used to qualify the full DNS domain name to the root level of the DNS namespace tree.

Background on DNS and the Internet

Domain Name System (DNS) was developed because of the need to provide a name-to-address mapping service for computers on the Internet. Before DNS was introduced in 1987, the practice of mapping friendly computer names to IP addresses was done mainly through the use of a shared static file, known as a Hosts file.

Originally, the Internet was small enough to use one centrally administered file that was published and downloaded using FTP for Internet-connected sites. Periodically, each Internet site would update its copy of the Hosts file, and updated versions of the Hosts file were posted to reflect network changes.

As the number of computers on the Internet grew, it became unworkable to have one centralized authority managing a single Hosts file for all Internet hosts. The file became increasingly larger, which made it harder to maintain and distribute to all sites in a current and updated form.

The DNS standard was developed to provide an alternative to Hosts files. RFCs 1034 and 1035 specify most of the core protocols and have been added to and updated by additional RFCs submitted to the Internet Engineering Task Force (IETF). The IETF reviews and approves new drafts continuously, so the standards for DNS evolve and change as needed.

For more information, see DNS RFCs.

Notes

  • DNS domain names are required to be unique at each level, but individual name labels can be reused in other domains. For example, the name "mailserver" can be used one time only in both the example.microsoft.com and microsoft.com domains.
  • For more information on the use of labels, FQDNs, and other DNS host naming requirements, see Choosing names.
  • Hosts files are supported as a local static file method of mapping DNS domain names for host computers to their IP addresses. When the DNS Client service is started, it preloads any mapped entries added to this file into the local DNS names caches.
  • The Hosts file is provided in the systemroot\System32\Drivers\Etc folder. To view or modify this file, you can use Notepad or another text-based editor. For more information about creating or editing the Hosts file, refer to the comments and examples in the file.


How DNS query works

When a DNS client needs to look up a name used in a program, it queries DNS servers to resolve the name. Each query message the client sends contains three pieces of information, specifying a question for the server to answer:

  • A specified DNS domain name, stated as a fully qualified domain name (FQDN)
  • A specified query type, which can either specify a resource record by type or a specialized type of query operation
  • A specified class for the DNS domain name.

    For Windows DNS servers, this should always be specified as the Internet (IN) class.

For example, the name specified could be the FQDN for a computer, such as "host-a.example.microsoft.com.", and the query type specified to look for an address (A) resource record by that name. Think of a DNS query as a client asking a server a two-part question, such as "Do you have any A resource records for a computer named 'hostname.example.microsoft.com.'?" When the client receives an answer from the server, it reads and interprets the answered A resource record, learning the IP address for the computer it asked for by name.

DNS queries resolve in a number of different ways. A client can sometimes answer a query locally using cached information obtained from a previous query. The DNS server can use its own cache of resource record information to answer a query. A DNS server can also query or contact other DNS servers on behalf of the requesting client to fully resolve the name, then send an answer back to the client. This process is known as recursion.

In addition, the client itself can attempt to contact additional DNS servers to resolve a name. When a client does so, it uses separate and additional queries based on referral answers from servers. This process is known as iteration.

In general, the DNS query process occurs in two parts:

  • A name query begins at a client computer and is passed to a resolver, the DNS Client service, for resolution.
  • When the query cannot be resolved locally, DNS servers can be queried as needed to resolve the name.

Both of these processes are explained in more detail in the following sections.

Part 1: The local resolver

The following figure shows an overview of the complete DNS query process.

How a DNS query works

As shown in the initial steps of the query process, a DNS domain name is used in a program on the local computer. The request is then passed to the DNS Client service for resolution using locally cached information. If the queried name can be resolved, the query is answered and the process is completed.

The local resolver cache can include name information obtained from two possible sources:

  • If a Hosts file is configured locally, any host name-to-address mappings from that file are preloaded into the cache when the DNS Client service is started.
  • Resource records obtained in answered responses from previous DNS queries are added to the cache and kept for a period of time.

If the query does not match an entry in the cache, the resolution process continues with the client querying a DNS server to resolve the name.

Part 2: Querying a DNS server

As indicated in the previous figure, the client queries a preferred DNS server. The actual server used during the initial client/server query part of the process is selected from a global list. For more information about how this global list is compiled and updated, see Client features.

When the DNS server receives a query, it first checks to see if it can answer the query authoritatively based on resource record information contained in a locally configured zone on the server. If the queried name matches a corresponding resource record in local zone information, the server answers authoritatively, using this information to resolve the queried name.

If no zone information exists for the queried name, the server then checks to see if it can resolve the name using locally cached information from previous queries. If a match is found here, the server answers with this information. Again, if the preferred server can answer with a positive matched response from its cache to the requesting client, the query is completed.

If the queried name does not find a matched answer at its preferred server — either from its cache or zone information — the query process can continue, using recursion to fully resolve the name. This involves assistance from other DNS servers to help resolve the name. By default, the DNS Client service asks the server to use a process of recursion to fully resolve names on behalf of the client before returning an answer. In most cases, the DNS server is configured, by default, to support the recursion process as shown in the following figure.

How recursion works

In order for the DNS server to do recursion properly, it first needs some helpful contact information about other DNS servers in the DNS domain namespace. This information is provided in the form of root hints, a list of preliminary resource records that can be used by the DNS service to locate other DNS servers that are authoritative for the root of the DNS domain namespace tree. Root servers are authoritative for the domain root and top-level domains in the DNS domain namespace tree. For more information, see Updating root hints.

By using root hints to find root servers, a DNS server is able to complete the use of recursion. In theory, this process enables any DNS server to locate the servers that are authoritative for any other DNS domain name used at any level in the namespace tree.

For example, consider the use of the recursion process to locate the name "host-b.example.microsoft.com." when the client queries a single DNS server. The process occurs when a DNS server and client are first started and have no locally cached information available to help resolve a name query. It assumes that the name queried by the client is for a domain name of which the server has no local knowledge, based on its configured zones.

First, the preferred server parses the full name and determines that it needs the location of the server that is authoritative for the top-level domain, "com". It then uses an iterative query to the "com" DNS server to obtain a referral to the "microsoft.com" server. Next, a referral answer comes from the "microsoft.com" server to the DNS server for "example.microsoft.com".

Finally, the "example.microsoft.com." server is contacted. Because this server contains the queried name as part of its configured zones, it responds authoritatively back to the original server that initiated recursion. When the original server receives the response indicating that an authoritative answer was obtained to the requested query, it forwards this answer back to the requesting client and the recursive query process is completed.

Although the recursive query process can be resource-intensive when performed as described above, it has some performance advantages for the DNS server. For example, during the recursion process, the DNS server performing the recursive lookup obtains information about the DNS domain namespace. This information is cached by the server and can be used again to help speed the answering of subsequent queries that use or match it. Over time, this cached information can grow to occupy a significant portion of server memory resources, although it is cleared whenever the DNS service is cycled on and off.

Alternate query responses

The previous discussion of DNS queries assumes that the process ends with a positive response returned to the client. However, queries can return other answers as well. These are the most common:

  • An authoritative answer
  • A positive answer
  • A referral answer
  • A negative answer

An authoritative answer is a positive answer returned to the client and delivered with the authority bit set in the DNS message to indicate the answer was obtained from a server with direct authority for the queried name.

A positive response can consist of the queried RR or a list of RRs (also known as an RRset) that fits the queried DNS domain name and record type specified in the query message.

A referral answer contains additional resource records not specified by name or type in the query. This type of answer is returned to the client if the recursion process is not supported. The records are meant to act as helpful reference answers that the client can use to continue the query using iteration.

A referral answer contains additional data such as resource records (RRs) that are other than the type queried. For example, if the queried host name was "www" and no A RRs for this name were found in this zone but a CNAME RR for "www" was found instead, the DNS server can include that information when responding to the client.

If the client is able to use iteration, it can make additional queries using the referral information in an attempt to fully resolve the name for itself. For more information, see How iteration works.

A negative response from the server can indicate that one of two possible results was encountered while the server attempted to process and recursively resolve the query fully and authoritatively:

  • An authoritative server reported that the queried name does not exist in the DNS namespace.
  • An authoritative server reported that the queried name exists but no records of the specified type exist for that name.

The resolver passes the results of the query, in the form of either a positive or negative response, back to the requesting program and caches the response.

Notes

  • If the resultant answer to a query is too long to be sent and resolved in a single UDP message packet, the DNS server can initiate a failover response over TCP port 53 to answer the client fully in a TCP connected session.

  • Disabling the use of recursion on a DNS server is generally done when DNS clients are being limited to resolving names to a specific DNS server, such as one located on your intranet. Recursion might also be disabled when the DNS server is incapable of resolving external DNS names, and clients are expected to fail over to another DNS server for resolution of these names.

    You can disable the use of recursion by configuring in the Advanced properties in the DNS console on the applicable server. For more information, see To disable recursion on the DNS server.

  • If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.
  • By default, DNS servers use several default timings when performing a recursive query and contacting other DNS servers. These are:
    • A recursion retry interval of 3 seconds. This is the length of time the DNS service waits before retrying a query made during a recursive lookup.
    • A recursion time-out interval of 15 seconds. This is the length of time the DNS service waits before failing a recursive lookup that has been retried.

    Under most circumstances, these parameters do not need adjustment. However, if you are using recursive lookups over a slow-speed WAN link, you might be able to improve server performance and query completion by making slight adjustments to the settings. For more information, see Tuning advanced server parameters.

How iteration works

Iteration is the type of name resolution used between DNS clients and servers when the following conditions are in effect:

  • The client requests the use of recursion, but recursion is disabled on the DNS server.
  • The client does not request the use of recursion when querying the DNS server.

An iterative request from a client tells the DNS server that the client expects the best answer the DNS server can provide immediately, without contacting other DNS servers.

When iteration is used, a DNS server answers a client based on its own specific knowledge about the namespace with regard to the names data being queried. For example, if a DNS server on your intranet receives a query from a local client for "www.microsoft.com", it might return an answer from its names cache. If the queried name is not currently stored in the names cache of the server, the server might respond by providing a referral — that is, a list of NS and A resource records for other DNS servers that are closer to the name queried by the client.

When a referral is made, the DNS client assumes responsibility to continue making iterative queries to other configured DNS servers to resolve the name. For example, in the most involved case, the DNS client might expand its search as far as the root domain servers on the Internet in an effort to locate the DNS servers that are authoritative for the "com" domain. Once it contacts the Internet root servers, it can be given further iterative responses from these DNS servers that point to actual Internet DNS servers for the "microsoft.com" domain. When the client is provided records for these DNS servers, it can send another iterative query to the external Microsoft DNS servers on the Internet, which can respond with a definitive and authoritative answer.

When iteration is used, a DNS server can further assist in a name query resolution beyond giving its own best answer back to the client. For most iterative queries, a client uses its locally configured list of DNS servers to contact other name servers throughout the DNS namespace if its primary DNS server cannot resolve the query.

How caching works

As DNS servers process client queries using recursion or iteration, they discover and acquire a significant store of information about the DNS namespace. This information is then cached by the server.

Caching provides a way to speed the performance of DNS resolution for subsequent queries of popular names, while substantially reducing DNS-related query traffic on the network.

As DNS servers make recursive queries on behalf of clients, they temporarily cache resource records (RRs). Cached RRs contain information obtained from DNS servers that are authoritative for DNS domain names learned while making iterative queries to search and fully answer a recursive query performed on behalf of a client. Later, when other clients place new queries that request RR information matching cached RRs, the DNS server can use the cached RR information to answer them.

When information is cached, a Time-To-Live (TTL) value applies to all cached RRs. As long as the TTL for a cached RR does not expire, a DNS server can continue to cache and use the RR again when answering queries by its clients that match these RRs. Caching TTL values used by RRs in most zone configurations are assigned the Minimum (default) TTL which is set used in the zone's start of authority (SOA) resource record. By default, the minimum TTL is 3,600 seconds (1 hour) but can be adjusted or, if needed, individual caching TTLs can be set at each RR.

Notes

  • You can install a DNS server as a caching-only server. For more information, see Using caching-only servers.
  • By default, DNS servers use a root hints file, Cache.dns, that is stored in the systemroot\System32\Dns folder on the server computer. The contents of this file are preloaded into server memory when the service is started and contain pointer information to root servers for the DNS namespace where you are operating DNS servers. For more information on this file or how it is used, see DNS-related files.


Understanding zones and zone transfer

Domain Name System (DNS) allows a DNS namespace to be divided up into zones, which store name information about one or more DNS domains. For each DNS domain name included in a zone, the zone becomes the authoritative source for information about that domain.

Understanding the difference between zones and domains

A zone starts as a storage database for a single DNS domain name. If other domains are added below the domain used to create the zone, these domains can either be part of the same zone or belong to another zone. Once a subdomain is added, it can then either be:

  • Managed and included as part of the original zone records, or
  • Delegated away to another zone created to support the subdomain

For example, the following figure shows the microsoft.com domain, which contains domain names for Microsoft. When the microsoft.com domain is first created at a single server, it is configured as a single zone for all of the Microsoft DNS namespace. If, however, the microsoft.com domain needs to use subdomains, those subdomains must be included in the zone or delegated away to another zone.

Difference between a zone and a domain

In this example, the example.microsoft.com domain shows a new subdomain — the example.microsoft.com domain — delegated away from the microsoft.com zone and managed in its own zone. However, the microsoft.com zone needs to contain a few resource records to provide the delegation information that references the DNS servers that are authoritative for the delegated example.microsoft.com subdomain.

If the microsoft.com zone does not use delegation for a subdomain, any data for the subdomain remains part of the microsoft.com zone. For example, the subdomain dev.microsoft.com is not delegated away but is managed by the microsoft.com zone.

Why zone replication and zone transfers are needed

Because of the important role that zones play in DNS, it is intended that they be available from more than one DNS server on the network to provide availability and fault tolerance when resolving name queries. Otherwise, if a single server is used and that server is not responding, queries for names in the zone can fail. For additional servers to host a zone, zone transfers are required to replicate and synchronize all copies of the zone used at each server configured to host the zone.

When a new DNS server is added to the network and is configured as a new secondary server for an existing zone, it performs a full initial transfer of the zone to obtain and replicate a full copy of resource records for the zone. For most earlier DNS server implementations, this same method of full transfer for a zone is also used when the zone requires updating after changes are made to the zone. For DNS servers running Windows Server 2003, the DNS service supports incremental zone transfer, a revised DNS zone transfer process for intermediate changes.

Incremental zone transfers

Incremental zone transfers are described in Request for Comments (RFC) 1995 as an additional DNS standard for replicating DNS zones. For more information about RFCs, see the RFC Editor Web site. When incremental transfers are supported by both a DNS server acting as the source for a zone and any servers that copy the zone from it, it provides a more efficient method of propagating zone changes and updates.

In earlier DNS implementations, any request for an update of zone data required a full transfer of the entire zone database using an AXFR query. With incremental transfer, an alternate query type (IXFR) can be used instead. This allows the secondary server to pull only those zone changes it needs to synchronize its copy of the zone with its source, either a primary or secondary copy of the zone maintained by another DNS server.

With IXFR zone transfers, differences between the source and replicated versions of the zone are first determined. If the zones are identified to be the same version — as indicated by the serial number field in the start of authority (SOA) resource record of each zone — no transfer is made.

If the serial number for the zone at the source is greater than at the requesting secondary server, a transfer is made of only those changes to resource records (RRs) for each incremental version of the zone. For an IXFR query to succeed and changes to be sent, the source DNS server for the zone must keep a history of incremental zone changes to use when answering these queries. The incremental transfer process requires substantially less traffic on a network and zone transfers are completed much faster.

Example: Zone transfer

A zone transfer might occur during any of the following scenarios:

  • When the refresh interval expires for the zone
  • When a secondary server is notified of zone changes by its master server
  • When the DNS Server service is started at a secondary server for the zone
  • When the DNS console is used at a secondary server for the zone to manually initiate a transfer from its master server

Zone transfers are always initiated at the secondary server for a zone and sent to their configured master servers which act as their source for the zone. Master servers can be any other DNS server that loads the zone, such as either the primary server for the zone or another secondary server. When the master server receives the request for the zone, it can reply with either a partial or full transfer of the zone to the secondary server.

As shown in the following figure, zone transfers between servers follow an ordered process. This process varies depending on whether a zone has been previously replicated, or if initial replication of a new zone is being performed.

Example: zone transfer

In this example, the following sequence is performed for a requesting secondary server — the destination server — for a zone and its source server, another DNS server that hosts the zone.

  1. During new configuration, the destination server sends an initial "all zone" transfer (AXFR) request to the master DNS server configured as its source for the zone.
  2. The master (source) server responds and fully transfers the zone to the secondary (destination) server.

    The zone is delivered to the destination server requesting the transfer with its version established by use of a Serial number field in the properties for the start of authority (SOA) resource record (RR). The SOA RR also contains a stated refresh interval in seconds (by default, 900 seconds or 15 minutes) to indicate when the destination server should next request to renew the zone with the source server.

  3. When the refresh interval expires, an SOA query is used by the destination server to request renewal of the zone from the source server.
  4. The source server answers the query for its SOA record.

    This response contains the serial number for the zone in its current state at the source server.

  5. The destination server checks the serial number of the SOA record in the response and determines how to renew the zone.

    If the value of the serial number in the SOA response is equal to its current local serial number, it concludes that the zone is the same at both servers and that a zone transfer is not needed. The destination server then renews the zone by resetting its refresh interval based on the value of this field in the SOA response from its source server.

    If the value of the serial number in the SOA response is higher than its current local serial number, it concludes that the zone has been updated and that a transfer is needed.

  6. If the destination server concludes that the zone has changed, it sends an IXFR query to the source server, containing its current local value for the serial number in the SOA record for the zone.
  7. The source server responds with either an incremental or full transfer of the zone.

    If the source server supports incremental transfer by maintaining a history of recent incremental zone changes for modified resource records, it can answer with an incremental zone transfer (IXFR) of the zone.

    If the source server does not support incremental transfer, or does not have a history of zone changes, it can answer with a full (AXFR) transfer of the zone instead.

Note

  • For servers running Windows 2000 and Windows Server 2003, incremental zone transfer through IXFR query is supported. For earlier versions of the DNS service and for many other DNS server implementations, incremental zone transfer is not available and only full-zone (AXFR) queries and transfers are used to replicate zones.

DNS Notify

Windows-based DNS servers support DNS Notify, an update to the original DNS protocol specification that permits a means of initiating notification to secondary servers when zone changes occur (RFC 1996). DNS notification implements a push mechanism for notifying a select set of secondary servers for a zone when it is updated. Servers that are notified can then initiate a zone transfer as described above to pull zone changes from their master servers and update their local replicas of the zone.

For secondaries to be notified by the DNS server acting as their configured source for a zone, each secondary server must first have its IP address in the notify list of the source server. When using the DNS console, this list is maintained in the Notify dialog box, which is accessible from the Zone Transfer tab located in zone Properties.

In addition to notifying the listed servers, the DNS console permits you to use the contents of the notify list as a means to restrict or limit zone transfer access to only those secondary servers specified in the list. This can help prevent an undesired attempt by an unknown or unapproved DNS server to pull, or request, zone updates. For more information, see To create and manage a notify list for a primary zone.

The following is a brief summary of the typical DNS notification process for zone updates:

  1. The local zone at a DNS server acting as a master server, a source for the zone to other servers, is updated. When the zone is updated at the master or source server, the serial number field in the SOA RR is also updated, indicating a new local version of the zone.
  2. The master server sends a DNS notify message to other servers that are part of its configured notify list.
  3. All secondary servers that receive the notify message can then respond by initiating a zone transfer request back to the notifying master server.

The normal zone transfer process can then continue as described in the previous section.

You cannot configure a notify list for a stub zone.

Important

  • Use DNS notification only to notify servers operating as secondary servers for a zone. For replication of directory-integrated zones, DNS notification is not needed.

    This is because any DNS servers that load a zone from Active Directory automatically poll the directory (as specified by the SOA resource record's Refresh Interval) to update and refresh the zone.

    In these cases, configuring a notify list can actually degrade system performance by causing unnecessary additional transfer requests for the updated zone.

Notes

  • By default, the DNS server will only allow a zone transfer to authoritative DNS servers listed in the name server (NS) resource records for the zone.
  • XOX


Reverse lookup

In most DNS lookups, clients typically perform a forward lookup, which is a search based on the DNS name of another computer as stored in an address (A) resource record. This type of query expects an IP address as the resource data for the answered response.

DNS also provides a reverse lookup process, enabling clients to use a known IP address during a name query and look up a computer name based on its address. A reverse lookup takes the form of a question, such as "Can you tell me the DNS name of the computer that uses the IP address 192.168.1.20?"

DNS was not originally designed to support this type of query. One problem for supporting the reverse query process is the difference in how the DNS namespace organizes and indexes names and how IP addresses are assigned. If the only method to answer the previous question was to search in all domains in the DNS namespace, a reverse query would take too long and require too much processing to be useful.

To solve this problem, a special domain, the in-addr.arpa domain, was defined in the DNS standards and reserved in the Internet DNS namespace to provide a practical and reliable way to perform reverse queries. To create the reverse namespace, subdomains within the in-addr.arpa domain are formed using the reverse ordering of the numbers in the dotted-decimal notation of IP addresses.

This reversed ordering of the domains for each octet value is needed because, unlike DNS names, when IP addresses are read from left to right, they are interpreted in the opposite manner. When an IP address is read from left to right, it is viewed from its most generalized information (an IP network address) in the first part of the address to the more specific information (an IP host address) contained in the last octets.

For this reason, the order of IP address octets must be reversed when building the in-addr.arpa domain tree. The IP addresses of the DNS in-addr.arpa tree can be delegated to companies as they are assigned a specific or limited set of IP addresses within the Internet-defined address classes.

Finally, the in-addr.arpa domain tree, as built into DNS, requires that an additional resource record (RR) type — the pointer (PTR) RR — be defined. This RR is used to create a mapping in the reverse lookup zone that typically corresponds to a host (A) named RR for the DNS computer name of a host in its forward lookup zone.

Note

  • The in-addr.arpa domain applies for use in all TCP/IP networks that are based on Internet Protocol version 4 (IPv4) addressing. The New Zone wizard automatically assumes that you are using this domain when creating a new reverse lookup zone.

    If you are installing DNS and configuring reverse lookup zones for an Internet Protocol version 6 (IPv6) network, you can specify an exact name in the New Zone wizard. This will permit you to create reverse lookup zones in the DNS console that can be used to support IPv6 networks, which uses a different special domain name, the ip6.int domain.

    Additional information is available on IPv6 and DNS, including examples of how to create and use ip6.int domain names in Request for Comments (RFC) 1886, "DNS Extensions to support IP version 6." For more information, refer directly to this RFC, which can be obtained from the RFC Editor Web site.

Example: Reverse query (for IPv4 networks)

The following figure shows an example of a reverse query initiated by a DNS client (host-b) to learn the name of another host (host-a) based on its IP address, 192.168.1.20.

Example: DNS reverse lookup

The reverse query process as shown in this figure occurs in the following steps:

  1. The client, "host-b", queries the DNS server for a pointer (PTR) RR that maps to the IP address of 192.168.1.20 for "host-a".

    Because the query is for PTR records, the resolver reverses the address and appends the in-addr.arpa domain to the end of the reverse address. This forms the fully qualified domain name ("20.1.168.192.in-addr.arpa.") for which to be searched in a reverse lookup zone.

  2. Once located, the authoritative DNS server for "20.1.168.192.in-addr.arpa" can respond with the PTR record information. This includes the DNS domain name for "host-a", completing the reverse lookup process.

Keep in mind that if the queried reverse name is not answerable from the DNS server, normal DNS resolution (either recursion or iteration) can be used to locate a DNS server that is authoritative for the reverse lookup zone and that contains the queried name. In this sense, the name resolution process used in a reverse lookup is identical to that of a forward lookup.

Note

  • The DNS console provides a means for you to configure a subnetted reverse lookup "classless" zone when the Advanced view is selected. This allows you to configure a zone in the in-addr.arpa domain for a limited set of assigned IP addresses where a nondefault IP subnet mask is used with those addresses. For more information, see Managing reverse lookup zones.

Inverse queries

Inverse queries are an outdated practice, originally proposed as part of the DNS standard to look up a host name based on its IP address. They use a nonstandard DNS query operation, and their use is limited to some of the earlier versions of Nslookup, a command-line utility for troubleshooting and testing DNS service.

The DNS service recognizes and accepts inverse query messages, answering them with a fake inverse query response. For DNS servers running in Windows NT Server 4.0, this support is available by default if the server computer has been updated to Service Pack 4 or later.

Notes

  • The configuration of PTR resource records and reverse lookup zones for identifying hosts by reverse query is strictly an optional part of the DNS standard implementation. You are not required to use reverse lookup zones, although for some networked applications, they are used to perform security checks.
  • XOX


Understanding forwarders

A forwarder is a Domain Name System (DNS) server on a network used to forward DNS queries for external DNS names to DNS servers outside of that network. You can also forward queries according to specific domain names using conditional forwarders.

A DNS server on a network is designated as a forwarder by having the other DNS servers in the network forward the queries they cannot resolve locally to that DNS server. By using a forwarder, you can manage name resolution for names outside of your network, such as names on the Internet, and improve the efficiency of name resolution for the computers in your network. For more information about forwarders and conditional forwarders, see Using forwarders.

The following figure illustrates how external name queries are directed using forwarders.

Example of a common forwarder configuration

For more information about directing external queries, see Directing queries through forwarders.

Without having a specific DNS server designated as a forwarder, all DNS servers can send queries outside of a network using their root hints. As a result, a lot of internal, and possibly critical, DNS information can be exposed on the Internet. In addition to this security and privacy issue, this method of resolution can result in a large volume of external traffic that is costly and inefficient for a network with a slow Internet connection or a company with high Internet service costs.

When you designate a DNS server as a forwarder, you make that forwarder responsible for handling external traffic, thereby limiting DNS server exposure to the Internet. A forwarder will build up a large cache of external DNS information because all of the external DNS queries in the network are resolved through it. In a small amount of time, a forwarder will resolve a good portion of external DNS queries using this cached data and thereby decrease the Internet traffic over the network and the response time for DNS clients.

A DNS server configured to use a forwarder will behave differently than a DNS server that is not configured to use a forwarder. A DNS server configured to use a forwarder behaves as follows:

  1. When the DNS server receives a query, it attempts to resolve this query using the primary and secondary zones that it hosts and its cache.
  2. If the query cannot be resolved using this local data, then it will forward the query to the DNS server designated as a forwarder.
  3. The DNS server will wait briefly for an answer from the forwarder before attempting to contact the DNS servers specified in its root hints.

When a DNS server forwards a query to a forwarder it sends a recursive query to the forwarder. This is different than the iterative query that a DNS server will send to an other DNS server during standard name resolution (name resolution that does not involve a forwarder).

Conditional forwarders

A conditional forwarder is a DNS server on a network that is used to forward DNS queries according to the DNS domain name in the query. For example, a DNS server can be configured to forward all the queries it receives for names ending with widgets.example.com to the IP address of a specific DNS server or to the IP addresses of multiple DNS servers.

Intranet name resolution

A conditional forwarder can be used to improve name resolution for domains within your intranet. Intranet name resolution can be improved by configuring DNS servers with forwarders for specific internal domain names. For example, all DNS servers in the domain widgets.example.com could be configured to forward queries for names that end with test.example.com to the authoritative DNS servers for merged.widgets.example.com, thereby removing the step of querying the root servers of example.com, or removing the step of configuring DNS servers in the widgets.example.com zone with secondary zones for test.example.com.

Internet name resolution

DNS servers can use conditional forwarders to resolve queries between the DNS domain names of companies that share information. For example, two companies, Widgets Toys and TailspinToys, want to improve how the DNS clients of Widgets Toys resolve the names of the DNS clients of Tailspin Toys. The administrators from Tailspin Toys inform the administrators of Widgets Toys about the set of DNS servers in the Tailspin Toys network where Widgets can send queries for the domain dolls.tailspintoys.com. The DNS servers within the Widgets Toys network are configured to forward all queries for names ending with dolls.tailspintoys.com to the designated DNS servers in the network for Tailspin Toys. Consequently, the DNS servers in the Widgets Toys network do not need to query their internal root servers, or the Internet root servers, to resolve queries for names ending with dolls.tailspintoys.com.


Understanding stub zones

A stub zone is a copy of a zone that contains only those resource records necessary to identify the authoritative Domain Name System (DNS) servers for that zone. A stub zone is used to keep a DNS server hosting a parent zone aware of the authoritative DNS servers for its child zone and thereby maintain DNS name resolution efficiency.

A stub zone consists of:

  • The start of authority (SOA) resource record, name server (NS) resource records, and the glue A resource records for the delegated zone.
  • The IP address of one or more master servers that can be used to update the stub zone.

The master servers for a stub zone are one or more DNS servers authoritative for the child zone, usually the DNS server hosting the primary zone for the delegated domain name.

For more information, see Using stub zones.

Stub zone resolution

When a DNS client performs a recursive query operation on a DNS server hosting a stub zone, the DNS server uses the resource records in the stub zone to resolve the query. The DNS server sends an iterative query to the authoritative DNS servers specified in the NS resource records of the stub zone as if it were using NS resource records in its cache. If the DNS server cannot find the authoritative DNS servers in its stub zone, the DNS server hosting the stub zone attempts standard recursion using its root hints.

The DNS server will store the resource records it receives from the authoritative DNS servers listed in a stub zone in its cache, but it will not store these resource records in the stub zone itself; only the SOA, NS, and glue A resource records returned in response to the query are stored in the stub zone. The resource records stored in the cache are cached according to the Time-to-Live (TTL) value in each resource record. The SOA, NS, and glue A resource records, which are not written to cache, expire according to the expire interval specified in the stub zone's SOA record, which is created during the creation of the stub zone and updated during transfers to the stub zone from the original, primary zone.

If the query was an iterative query, the DNS server returns a referral containing the servers specified in the stub zone.

Communication between DNS servers hosting parent and child zones

A DNS server that has delegated a domain to a child zone on a different DNS server is made aware of new authoritative DNS servers for the child zone only when the resource records for these new DNS servers are added to the parent zone hosted on the DNS server. This is a manual process and requires that the administrators for the different DNS servers communicate often. With stub zones, a DNS server hosting a stub zone for one of its delegated domains can obtain updates of the authoritative DNS servers for the child zone when the stub zone is updated. The update is performed from the DNS server hosting the stub zone and the administrator for the DNS server hosting the child zone does not need to be contacted. This functionality is explained in the following example.

Stub zone scenario

A DNS server authoritative for the parent zone, example.com, has delegated a subdomain, widgets.example.com, to separate DNS servers. When the delegation for the domain widgets.example.com was originally performed, the parent zone contained only two NS records for the widgets.example.com zone's authoritative DNS servers. Later, administrators of the child zone configured additional DNS servers as authoritative for the zone but did not notify the administrators of the DNS server hosting the parent zone, example.com. As a result, the DNS server hosting the parent zone, example.com, is unaware of the new DNS servers authoritative for its child zone, widgets.example.com, and continues to query the only two authoritative DNS servers of which it is aware.

This situation is remedied by configuring the DNS server authoritative for the parent zone, example.com, to host a stub zone for the delegated domain, widgets.example.com. When the administrator of the authoritative DNS server for example.com updates the stub zone, it queries the stub zone's master servers to obtain the authoritative DNS server resource records for widgets.example.com. Consequently, the DNS server authoritative for the parent zone will learn about the new DNS servers authoritative for the widgets.example.com child zone and be able to perform recursion to all of the child zone's authoritative DNS servers.

The following figure demonstrates how a stub zone hosted on the same DNS server as the parent zone updates the authoritative server data for the child zone.

Stub zone is updated with DNS server data from the master server for the delegated zone

For more information, see Active Directory–integrated stub zones, Understanding zones and zone transfer, and Delegating zones.


Dynamic update

Dynamic update enables DNS client computers to register and dynamically update their resource records with a DNS server whenever changes occur. This reduces the need for manual administration of zone records, especially for clients that frequently move or change locations and use DHCP to obtain an IP address.

The DNS Client and Server services support the use of dynamic updates, as described in Request for Comments (RFC) 2136, "Dynamic Updates in the Domain Name System." The DNS Server service allows dynamic update to be enabled or disabled on a per-zone basis at each server configured to load either a standard primary or directory-integrated zone. By default, the DNS Client service will dynamically update host (A) resource records (RRs) in DNS when configured for TCP/IP. For more information about RFCs, see DNS RFCs.

How client and server computers update their DNS names

By default, computers that are statically configured for TCP/IP attempt to dynamically register host (A) and pointer (PTR) resource records (RRs) for IP addresses configured and used by their installed network connections. By default, all computers register records based on their fully qualified domain name (FQDN).

The primary full computer name, a FQDN, is based on the primary DNS suffix of a computer appended to its Computer name.

Both of these settings are displayed or configured from the Computer Name tab in System properties. For more information, see To view system properties or To configure the primary DNS suffix for a client computer.

Notes

  • By default, the DNS client on XOX does not attempt dynamic update over a Remote Access Service (RAS) or virtual private network (VPN) connection. To modify this configuration, you can modify the advanced TCP/IP settings of the particular network connection or modify the registry. For more information, see To configure TCP/IP to use DNS and the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone named with a single-label name is considered a TLD zone, for example, com, edu, blank, my-company. To configure the DNS client to allow the dynamic update of TLD zones, you can use the Update Top Level Domain Zones policy setting or modify the registry.
  • By default, the primary DNS suffix portion of a computer's FQDN is the same as the name of the Active Directory domain to which the computer is joined. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by modifying the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is managed by the domain administrator using Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP).

    • For more information, see Programming interfaces and Directory access protocol.

Dynamic updates can be sent for any of the following reasons or events:

  • An IP address is added, removed, or modified in the TCP/IP properties configuration for any one of the installed network connections.
  • An IP address lease changes or renews with the DHCP server any one of the installed network connections. For example, when the computer is started or if the ipconfig /renew command is used.
  • The ipconfig /registerdns command is used to manually force a refresh of the client name registration in DNS.
  • At startup time, when the computer is turned on.
  • A member server is promoted to a domain controller.

When one of the previous events triggers a dynamic update, the DHCP Client service (not the DNS Client service) sends updates. This is designed so that if a change to the IP address information occurs because of DHCP, corresponding updates in DNS are performed to synchronize name-to-address mappings for the computer. The DHCP Client service performs this function for all network connections used on the system, including connections not configured to use DHCP.

Notes

  • The process of how dynamic updates are performed for computers running Windows 2000, XOX, or Windows Server 2003 operating systems that use DHCP to obtain their IP address is different than is described in this section. For more information, see Using DNS servers with DHCP.
  • The update process described in this section assumes that installation defaults are in effect for computers running Windows 2000, XOX, or servers running Windows Server 2003. Specific names and update behavior is tunable where advanced TCP/IP properties are configured to use non-default DNS settings.

    In addition to the full computer name (or primary name) of the computer, additional connection-specific DNS names can be configured and optionally registered or updated in DNS. For more information, see Configuring multiple names or To configure TCP/IP to use DNS.

Example: How dynamic update works

Dynamic updates are typically requested when either a DNS name or IP address changes on the computer. For example, suppose a client named "oldhost" is first configured in System properties with the following names:

Computer name | oldhost
DNS domain name of computer | example.microsoft.com
Full computer name | oldhost.example.microsoft.com

In this example, no connection-specific DNS domain names are configured for the computer. Later, the computer is renamed from "oldhost" to "newhost", resulting in the following name changes on the system:

Computer name | newhost
DNS domain name of computer | example.microsoft.com
Full computer name | newhost.example.microsoft.com

Once the name change is applied in System properties, you are prompted to restart the computer. When the computer restarts Windows, the DHCP Client service performs the following sequence to update DNS:

  1. The DHCP Client service sends a start of authority (SOA) type query using the DNS domain name of the computer.

    The client computer uses the currently configured FQDN of the computer (such as "newhost.example.microsoft.com") as the name specified in this query.

  2. The authoritative DNS server for the zone containing the client FQDN responds to the SOA-type query.

    For standard primary zones, the primary server (owner) returned in the SOA query response is fixed and static. It always matches the exact DNS name as it appears in the SOA RR stored with the zone. If, however, the zone being updated is directory-integrated, any DNS server loading the zone can respond and dynamically insert its own name as the primary server (owner) of the zone in the SOA query response.

  3. The DHCP Client service then attempts to contact the primary DNS server.

    The client processes the SOA query response for its name to determine the IP address of the DNS server authorized as the primary server for accepting its name. It then proceeds to perform the following sequence of steps as needed to contact and dynamically update its primary server:

    1. It sends a dynamic update request to the primary server determined in the SOA query response.

      If the update succeeds, no further action is taken.

    2. If this update fails, the client next sends an NS-type query for the zone name specified in the SOA record.
    3. When it receives a response to this query, it sends an SOA query to the first DNS server listed in the response.
    4. After the SOA query is resolved, the client sends a dynamic update to the server specified in the returned SOA record.

      If the update succeeds, no further action is taken.

    5. If this update fails, then the client repeats the SOA query process by sending to the next DNS server listed in the response.
  4. Once the primary server is contacted that can perform the update, the client sends the update request and the server processes it.

    The contents of the update request include instructions to add A (and possibly PTR) RRs for "newhost.example.microsoft.com" and remove these same record types for "oldhost.example.microsoft.com", the name that was previously registered.

    The server also checks to ensure that updates are permitted for the client request. For standard primary zones, dynamic updates are not secured, so any client attempt to update succeeds. For Active Directory–integrated zones, updates are secured and performed using directory-based security settings. For more information, see Secure dynamic updates.

Dynamic updates are sent or refreshed periodically. By default, computers send a refresh once every 7 days. If the update results in no changes to zone data, the zone remains at its current version and no changes are written. Updates result in actual zone changes or increased zone transfer only if names or addresses actually change.

Note that names are not removed from DNS zones if they become inactive or are not updated within the refresh interval (7 days). DNS does not use a mechanism to release or tombstone names, although DNS clients do attempt to delete or update old name records when a new name or address change is applied.

When the DHCP Client service registers A and PTR resource records for a computer, it uses a default caching Time to Live (TTL) of 15 minutes for host records. This determines how long other DNS servers and clients cache a computer's records when they are included in a query response.

Secure dynamic update

DNS update security is available only for zones that are integrated into Active Directory. Once you directory-integrate a zone, access control list (ACL) editing features are available in the DNS console so you can add or remove users or groups from the ACL for a specified zone or resource record. For more information, see To modify security for a resource record or To modify security for a directory-integrated zone.

By default, dynamic update security for DNS servers and clients can be handled as follows:

  • DNS clients attempt to use unsecured dynamic update first. If an unsecured update is refused, clients try to use secure update.

    Also, clients use a default update policy that permits them to attempt to overwrite a previously registered resource record, unless they are specifically blocked by update security.

  • Once a zone becomes Active Directory–integrated, DNS servers running Windows Server 2003 default to allowing only secure dynamic updates.

    When using standard zone storage, the default for the DNS Server service is to not allow dynamic updates on its zones. For zones that are either directory-integrated or use standard file-based storage, you can change the zone to allow all dynamic updates which permits all updates to be accepted.

Important

  • The DHCP Server service can perform proxy registration and update of DNS records for legacy clients that do not support dynamic updates.

    For information, see Using DNS servers with DHCP.

Notes

  • Dynamic update is a recent additional DNS standard specification, defined in RFC 2136. For more information, refer to the RFC. For information on obtaining RFCs, see TCP/IP RFCs.
  • For more information about DNS dynamic updates and secure updates, see Microsoft Windows Deployment and Resource Kits.
  • The dynamic registration of DNS resource records can be restricted with the use of registry entries. For more information, see article Q246804, "How to Enable/Disable Windows 2000 Dynamic DNS Registrations," in the Microsoft Knowledge Base. (http://www.microsoft.com/)


Active Directory integration

The DNS Server service is integrated into the design and implementation of Active Directory. Active Directory provides an enterprise-level tool for organizing, managing, and locating resources in a network.

Note

  • XOX

When deploying DNS servers with Active Directory, consider the following:

  • DNS is required for locating domain controllers running Windows Server 2003.

    The Net Logon service uses new DNS server support to provide registration of domain controllers in your DNS domain namespace.

  • DNS servers running Windows Server 2003 can use Active Directory for storing and replicating your zones.

    By directory integrating your zones, you can take advantage of DNS features such as secure dynamic updates and record aging and scavenging features.

    For more information, see either Secure dynamic update and Understanding aging and scavenging.

How DNS integrates with Active Directory

When you install Active Directory on a server, you promote the server to the role of a domain controller for a specified domain. When completing this process, you are prompted to specify a DNS domain name for the Active Directory domain for which you are joining and promoting the server.

If during this process, a DNS server authoritative for the domain that you specified either cannot be located on the network or does not support the DNS dynamic update protocol, you are prompted with the option to install a DNS server. This option is provided because a DNS server is required to locate this server or other domain controllers for members of an Active Directory domain. For more information about how computers locate domain controllers using DNS, see the Microsoft Windows Deployment and Resource Kits.

Once you have installed Active Directory, you have two options for storing and replicating your zones when operating the DNS server at the new domain controller:

  • Standard zone storage, using a text-based file.

    Zones stored this way are located in .Dns files that are stored in the systemroot\System32\Dns folder on each computer operating a DNS server. Zone file names correspond to the name you choose for the zone when creating it, such as example.microsoft.com.dns if the zone name was "example.microsoft.com."

  • Directory-integrated zone storage, using the Active Directory database.

    Zones stored this way are located in the Active Directory tree under the domain or application directory partition. Each directory-integrated zone is stored in a dnsZone container object identified by the name you choose for the zone when creating it. For more information, see DNS zone replication in Active Directory and Directory data store.

Benefits of Active Directory integration

For networks deploying DNS to support Active Directory, directory-integrated primary zones are strongly recommended and provide the following benefits:

  • Multimaster update and enhanced security based on the capabilities of Active Directory.

    In a standard zone storage model, DNS updates are conducted based upon a single-master update model. In this model, a single authoritative DNS server for a zone is designated as the primary source for the zone.

    This server maintains the master copy of the zone in a local file. With this model, the primary server for the zone represents a single fixed point of failure. If this server is not available, update requests from DNS clients are not processed for the zone.

    With directory-integrated storage, dynamic updates to DNS are conducted based upon a multimaster update model.

    In this model, any authoritative DNS server, such as a domain controller running a DNS server, is designated as a primary source for the zone. Because the master copy of the zone is maintained in the Active Directory database, which is fully replicated to all domain controllers, the zone can be updated by the DNS servers operating at any domain controller for the domain.

    With the multimaster update model of Active Directory, any of the primary servers for the directory-integrated zone can process requests from DNS clients to update the zone as long as a domain controller is available and reachable on the network.

    Also, when using directory-integrated zones, you can use access control list (ACL) editing to secure a dnsZone object container in the directory tree. This feature provides granulated access to either the zone or a specified RR in the zone.

    For example, an ACL for a zone RR can be restricted so that dynamic updates are only allowed for a specified client computer or a secure group such as a domain administrators group. This security feature is not available with standard primary zones.

    Note that when you change the zone type to be directory-integrated, the default for updating the zone changes to allow only secure updates. Also, while you may use ACLs on DNS-related Active Directory objects, ACLs may only be applied to the DNS client service.

  • Zones are replicated and synchronized to new domain controllers automatically whenever a new one is added to an Active Directory domain.

    Although DNS service can be selectively removed from a domain controller, directory-integrated zones are already stored at each domain controller, so zone storage and management is not an additional resource. Also, the methods used to synchronize directory-stored information offer performance improvement over standard zone update methods, which can potentially require transfer of the entire zone.

  • By integrating storage of your DNS zone databases in Active Directory, you can streamline database replication planning for your network.

    When your DNS namespace and Active Directory domains are stored and replicated separately, you need to plan and potentially administer each separately. For example, when using standard DNS zone storage and Active Directory together, you would need to design, implement, test, and maintain two different database replication topologies. For instance, one replication topology is needed for replicating directory data between domain controllers, and another topology would be needed for replicating zone databases between DNS servers.

    This can create additional administrative complexity for planning and designing your network and allowing for its eventual growth. By integrating DNS storage, you unify storage management and replication issues for both DNS and Active Directory, merging and viewing them together as a single administrative entity.

  • Directory replication is faster and more efficient than standard DNS replication.

    Because Active Directory replication processing is performed on a per-property basis, only relevant changes are propagated. This allows less data to be used and submitted in updates for directory-stored zones.

Notes

  • Only primary zones can be stored in the directory. A DNS server cannot store secondary zones in the directory. It must store them in standard text files. The multimaster replication model of Active Directory removes the need for secondary zones when all zones are stored in Active Directory.
  • The DNS Server service includes an option to initialize the DNS Server service by reading parameters stored in the Active Directory database and the server registry. This is the default boot option. For more information, see Modifying server defaults.
  • For more information about configuring DNS for Active Directory integration, see Configure a DNS server for use with Active Directory and Checklist: Verifying DNS before installing Active Directory.


DNS zone replication in Active Directory

DNS zones can be stored in the domain or application directory partitions of Active Directory. A partition is a data structure within Active Directory used to distinguish data for different replication purposes. For more information, see Active Directory integration.

Important

  • If you are changing the storage of a zone from the domain partition to an application directory partition, such as following the promotion of a new Windows Server 2003 domain controller in an existing Windows 2000 domain, the domain controller holding the domain naming master role must be running Windows Server 2003 for the DNS application directory partitions to exist. If you receive an error when changing the storage of a zone from the domain partition to an application directory partition, transfer the domain naming master role to a domain controller running Windows Server 2003, create the default DNS application directory partitions, and try again. For more information about creating the default DNS application directory partitions and transfering the domain naming master role, see To create the default DNS application directory partitions; To transfer the domain naming master role.

The following table describes the available zone replication scopes for Active Directory–integrated DNS zone data.

Zone replication scope | Description
All DNS servers in the Active Directory forest | Replicates zone data to all DNS servers running on domain controllers in the Active Directory forest. Usually, this is the broadest scope of replication.
All DNS servers in the Active Directory domain | Replicates zone data to all DNS servers running on domain controllers in the Active Directory domain. This option is the default setting for Active Directory–integrated DNS zone replication in the Windows Server 2003 family.
All domain controllers in the Active Directory domain | Replicates zone data to all domain controllers in the Active Directory domain. If you want Windows 2000 DNS servers to load an Active Directory zone, this setting must be selected for that zone.
All domain controllers in a specified application directory partition | Replicates zone data according to the replication scope of the specified application directory partition. For a zone to be stored in the specified application directory partition, the DNS server hosting the zone must be enlisted in the specified application directory partition. For more information, see To create a DNS application directory partition and To enlist a DNS server in a DNS application directory partition.

When deciding which replication option to choose, consider that the broader the replication scope, the greater the network traffic caused by replication. For example, if you choose to have Active Directory–integrated DNS zone data replicated to all DNS servers in the forest, this will produce greater network traffic than replicating the DNS zone data to all DNS servers in a single Active Directory domain in that forest. For information about changing zone replication scope, see To change zone replication scope.

Notes

  • XOX
  • Active Directory–integrated DNS zone data stored in an application directory partition is not replicated to the global catalog for the forest. The domain controller that contains the global catalog can also host application directory partitions, but it will not replicate this data to its global catalog.

    Active Directory–integrated DNS zone data stored in a domain partition is replicated to all domain controllers in its Active Directory domain and a portion of this data is stored in the global catalog. This setting is used to support Windows 2000.

  • If an application directory partition's replication scope replicates across Active Directory sites, replication will occur with the same intersite replication schedule as used for domain partition data.
  • Root hints are stored in the domain-wide application directory partition if the domain functional level is set to Windows Server 2003. If the domain functional level is set to Windows 2000 mixed or Windows 2000 native, root hints are stored in the domain partition. For more information about functional levels, see Domain and forest functionality.
  • By default, the Net Logon service registers domain controller locator (Locator) DNS resource records for the application directory partitions hosted on a domain controller in the same manner as it registers domain controller locator (Locator) DNS resource records for the domain partition hosted on a domain controller.


DNS requirements for installing Active Directory

When you install Active Directory on a member server, the member server is promoted to a domain controller. Active Directory uses DNS as the location mechanism for domain controllers, enabling computers on the network to obtain IP addresses of domain controllers.

During the installation of Active Directory, the service (SRV) and address (A) resource records are dynamically registered in DNS, which are necessary for the successful functionality of the domain controller locator (Locator) mechanism.

To find domain controllers in a domain or forest, a client queries DNS for the SRV and A DNS resource records of the domain controller, which provide the client with the names and IP addresses of the domain controllers. In this context, the SRV and A resource records are referred to as Locator DNS resource records.

When adding a domain controller to a forest, you are updating a DNS zone hosted on a DNS server with the Locator DNS resource records and identifying the domain controller. For this reason, the DNS zone must allow dynamic updates (RFC 2136) and the DNS server hosting that zone must support the SRV resource records (RFC 2782) to advertise the Active Directory directory service. For more information about RFCs, see DNS RFCs.

If the DNS server hosting the authoritative DNS zone is not a server running Windows 2000 or Windows Server 2003, contact your DNS administrator to determine if the DNS server supports the required standards. If the server does not support the required standards, or the authoritative DNS zone cannot be configured to allow dynamic updates, then modification is required to your existing DNS infrastructure.

For more information, see Checklist: Verifying DNS before installing Active Directory and Using the Active Directory Installation Wizard.

Important

  • The DNS server used to support Active Directory must support SRV resource records for the Locator mechanism to function. For more information, see Service location (SRV) resource records.
  • It is recommended that the DNS infrastructure allows dynamic updates of Locator DNS resource records (SRV and A) before installing Active Directory, but your DNS administrator may add these resource records manually after installation.

    After installing Active Directory, these records can be found on the domain controller in the following location: systemroot\System32\Config\Netlogon.dns


DNS requirements for joining an Active Directory domain

Active Directory uses Domain Name System (DNS) to locate domain controllers, enabling computers joining the network to obtain a domain controller's IP address, and then begin the process of network authentication.

Computers joining an Active Directory domain must satisfy the following three DNS requirements:

  • The computer must be configured with the IP address of a preferred DNS server.
  • The _ldap._tcp.dc._msdcs.DNSDomainName service (SRV) resource record must exist in DNS.
  • The address (A) resource record for the DNS name of the domain controllers specified in the data field of the _ldap._tcp.dc._msdcs.DNSDomainName SRV resource record must exist in DNS.

Configuring a computer’s preferred DNS server

You must configure the computer with the static IP address of a preferred DNS server manually or assign the IP address of a preferred DNS server using Dynamic Host Configuration Protocol (DHCP).

For more information, see To configure a computer's preferred DNS server.

Configuring the required DNS resource records

Computers joining an Active Directory domain need the following resource records in DNS to locate a domain controller:

  • _ldap._tcp.dc._msdcs.DNSDomainName SRV resource record, which identifies the name of the domain controller that hosts the Active Directory domain.

    DNSDomainName is the DNS name of the Active Directory domain the computer is attempting to join.

  • A corresponding address (A) resource record that identifies the IP address for the domain controller listed in the _ldap._tcp.dc._msdcs.DNSDomainName SRV resource record.

For more information, see To verify the DNS resource records needed to join an Active Directory domain; To configure TCP/IP to use DNS.


Understanding aging and scavenging

DNS servers running Windows Server 2003 support aging and scavenging features. These features are provided as a mechanism for performing cleanup and removal of stale resource records (RRs), which can accumulate in zone data over time.

With dynamic update, RRs are automatically added to zones when computers start on the network. However, in some cases, they are not automatically removed when computers leave the network. For example, if a computer registers its own host (A) RR at startup and is later improperly disconnected from the network, its host (A) RR might not be deleted. If your network has mobile users and computers, this situation can occur frequently.

If left unmanaged, the presence of stale RRs in zone data might cause some problems. The following are examples:

  • If a large number of stale RRs remain in server zones, they can eventually take up server disk space and cause unnecessarily long zone transfers.
  • DNS servers loading zones with stale RRs might use outdated information to answer client queries, potentially causing the clients to experience name resolution problems on the network.
  • The accumulation of stale RRs at the DNS server can degrade its performance and responsiveness.
  • In some cases, the presence of a stale RR in a zone could prevent a DNS domain name from being used by another computer or host device.

To solve these problems, the DNS Server service has the following features:

  • Time stamping, based on the current date and time set at the server computer, for any RRs added dynamically to primary-type zones. In addition, time stamps are recorded in standard primary zones where aging/scavenging is enabled.

    For RRs that you add manually, a time stamp value of zero is used, indicating that they are not affected by the aging process and can remain without limitation in zone data unless you otherwise change their time stamp or delete them.

  • Aging of RRs in local data, based on a specified refresh time period, for any eligible zones.

    Only primary type zones that are loaded by the DNS Server service are eligible to participate in this process.

  • Scavenging for any RRs that persist beyond the specified refresh period.

    When a DNS server performs a scavenging operation, it can determine that RRs have aged to the point of becoming stale and remove them from zone data. Servers can be configured to perform recurring scavenging operations automatically, or you can initiate an immediate scavenging operation at the server.

    For more information, see either To enable automatic scavenging of stale resource records or To start immediate scavenging of stale resource records.

Caution

  • By default, the aging and scavenging mechanism for the DNS Server service is disabled. It should only be enabled when all parameters are fully understood. Otherwise, the server could be accidentally configured to delete records that should not be deleted. If a record is accidentally deleted, not only will users fail to resolve queries for that record, but any user can create the record and take ownership of it, even on zones configured for secure dynamic update.

The server uses the contents of each RR-specific time stamp, along with other aging/scavenging properties that you can adjust or configure, to determine when it scavenges records.

Prerequisites for aging/scavenging

Before the aging and scavenging features of DNS can be used, several conditions must be met:

  1. Scavenging and aging must be enabled both at the DNS server and on the zone.

    By default, aging and scavenging of resource records is disabled.

  2. Resource records must either be dynamically added to zones or manually modified to be used in aging and scavenging operations.

    Typically, only those resource records added dynamically using the DNS dynamic update protocol are subject to aging and scavenging. For more information, see Dynamic update.

    You can, however, enable scavenging for other resource records added through non-dynamic means. For records added to zones in this way, either by loading a text-based zone file from another DNS server or by manually adding them to a zone, a time stamp of zero is set. This makes these records ineligible for use in aging/scavenging operations.

    In order to change this default, you can administer these records individually, to reset and permit them to use a current (non-zero) time stamp value. This enables these records to become aged and scavenged.

    For more information, see To reset scavenging and aging properties for a specified resource record.

Note

  • In the case of changing a zone from standard primary to Active Directory–integrated, you might want to enable scavenging of all existing resource records in the zone. To enable aging for all existing resource records in a zone, you can use the AgeAllRecords command, which is available through the dnscmd command-line tool. For more information, see Server administration using Dnscmd.

Aging/scavenging terminology

The following table indicates new or revised terms that have been introduced to help specifically when discussing aging and scavenging.

Term | Description
Resource record (RR) time stamp | A date and time value used by the DNS server to determine removal of the resource record when it performs aging and scavenging operations.
Current server time | The current date and time on the DNS server. This number can be expressed as an exact numeric value at any point in time.
No-refresh interval An interval of time, determined for each zone, as bounded by the following two events:
  1. The date and time when the record was last refreshed and its time stamp set.
  2. The date and time when the record next becomes eligible to be refreshed and have its time stamp reset.

This value is needed to decrease the number of write operations to the Active Directory database. By default, this interval is set to 7 days. It should not be increased to an unreasonably high level, because the benefits of the aging and scavenging feature might either be lost or diminished.
Refresh interval An interval of time, determined for each zone, as bounded by the following two distinct events:
  1. The earliest date and time when the record becomes eligible to be refreshed and have its time stamp reset.
  2. The earliest date and time when the record becomes eligible to be scavenged and removed from the zone database.

This value should be large enough to allow all clients to refresh their records. By default, this interval is set to 7 days. It should not be increased to an unreasonably high level, because the benefits of the aging and scavenging feature might either be lost or diminished.
Start scavenging time | A specific time, expressed as a number. This time is used by the server to determine when a zone becomes available for scavenging. For more information, see When scavenging can start.
Scavenging period | When automatic scavenging is enabled at the server, this period represents the time between repetitions of the automated scavenging process. The default value for this is 7 days. To prevent deterioration of DNS server performance, the minimum allowed value for this is 1 hour.
Record refresh When a DNS dynamic update is processed for a resource record when only the resource record time stamp, and no other characteristics of the record, are revised.

Refreshes generally occur for the following reasons:

  1. When a computer is restarted on the network and, if at startup, its name and IP address information are consistent with the same name and address information it used prior to being shut down, it sends a refresh to renew its associated resource records for this information.
  2. A periodic refresh is sent by the computer while it is running.

    The XOX and Windows Server 2003 DNS Client service renews DNS registration of client resource records every 24 hours. When this dynamic update occurs, if the dynamic update request does not cause modification to the DNS database, then it is considered to be a refresh and not a resource record update.

  3. Other network services make refresh attempts, such as: DHCP servers which renew client address leases, cluster servers which register and update records for a cluster, and the Net Logon service, which can register and update resource records used by Active Directory domain controllers.
Record update When a DNS dynamic update is processed for a resource record where other characteristics of the record in addition to its time stamp are revised.

Updates generally occur for the following reasons:

  1. When a new computer is added to the network and, at startup, it sends an update to register its resource records for the first time with its configured zone.
  2. When a computer with existing records in the zone has a change in IP address, causing updates to be sent for its revised name-to-address mappings in DNS zone data.
  3. When the Net Logon service registers a new Active Directory domain controller.
Scavenging servers An optional advanced zone parameter that enables you to specify a restricted list of IP addresses for DNS servers that are enabled to perform scavenging of the zone.

By default, if this parameter is not specified, all DNS servers that load a directory-integrated zone (also enabled for scavenging) attempt to perform scavenging of the zone. In some cases, this parameter can be useful if it is preferable that scavenging only be performed at some servers loading the directory-integrated zone.

To set this parameter, you must specify the list of IP addresses for the servers enabled to scavenge the zone in the ScavengingServers parameter for the zone. This can be done using the dnscmd command, a command-line based tool for administering Windows DNS servers. For more information, see Server administration using Dnscmd.

When scavenging can start

Once all prerequisites for enabling the use of scavenging are met, it can start for a server zone when the current server time is greater than the value of the start scavenging time for the zone.

The server sets the time value to start scavenging on a per-zone basis whenever one of the following events occurs:

  • Dynamic updates are enabled for the zone.
  • A change in the state of the Scavenge stale resource records check box is applied. You can use the DNS console to modify this setting at either an applicable DNS server or one of its primary zones.
  • The DNS server loads a primary zone enabled to use scavenging.

    This can occur when the server computer is started or when the DNS Server service is started.

  • When a zone resumes service after having been paused.

When the previous events occur, the DNS server sets the value of start scavenging time by calculating the following sum:

Current server time + Refresh interval = Start scavenging time

This value is used as a basis of comparison during scavenging operations.

Example of the aging/scavenging process for a sample record

To understand the process of aging and scavenging at the server, consider the life span and successive stages of a single resource record, as it is added to a server and zone where this process is in effect and then aged and removed from the database.

  1. A sample DNS host, "host-a.example.microsoft.com", registers its host (A) resource record at the DNS server for a zone where aging/scavenging is enabled for use.
  2. When registering the record, the DNS server places a time stamp on this record based on current server time.

    After the record time stamp is written, the DNS server does not accept refreshes for this record for the duration of the zone no-refresh interval. It can, however, accept updates prior to that time. For example, if the IP address for "host-a.example.microsoft.com" changes, the DNS server can accept the update. In this case, the server also updates (resets) the record time stamp.

  3. Upon expiration of the no-refresh period, the server begins to accept attempts to refresh this record.

    Once the initial no-refresh period ends, the refresh period immediately begins for the record. During this time, the server does not suppress attempts to refresh the record for its remaining life span.

  4. During and after the refresh period, if the server receives a refresh for the record, it processes it.

    This resets the time stamp for the record based on the method described in step 2.

  5. When subsequent scavenging is performed by the server for the "example.microsoft.com" zone, the record (and all other zone records) are examined by the server.

    Each record is compared to current server time on the basis of the following sum to determine whether the record should be removed:

    Record time stamp + No-refresh interval for zone + Refresh interval for zone

    • If the value of this sum is greater than current server time, no action is taken and the record continues to age in the zone.
    • If the value of this sum is less than current server time, the record is deleted both from any zone data currently loaded in server memory and also from the applicable DnsZone object store in Active Directory for the directory-integrated "example.microsoft.com" zone.

Note

  • For more information, see Managing the aging and scavenging of server data.


Unicode character support

Originally, Internet host names were restricted to the character set specified in Request for Comments (RFCs) 952 and 1123. These restrictions include limiting names to using uppercase and lowercase letters (A-Z, a-z), numbers (0-9) and hyphens (-). In addition, the first character of the DNS name can be a number and names must be encoded and represented using US-ASCII-based characters.

These requirement were maintained when DNS was introduced as part of RFC 1035, one of the core DNS standards specifications. For use of DNS in international settings, this requirement has significant limitations where extended character sets are used for local naming standards.

To remove these limitations, Microsoft expands DNS character support beyond the RFC 1035 specification. The DNS service now provides enhanced default support for UTF-8, a Unicode transformation format.

For more information about RFCs, see the RFC Editor Web site.

What is UTF-8?

UTF-8 is the recommended character set for protocols evolving beyond the use of ASCII. The UTF-8 protocol provides for support of extended ASCII characters and translation of UCS-2, a 16-bit Unicode character set that encompasses most of the world's writing systems. UTF-8 enables a far greater range of names than can be achieved using ASCII or extended ASCII encoding for character data.

Computers running Windows 2000, XOX, and Windows Server 2003 operating systems are UTF-8 aware. This means that when UTF-8 encoded characters are received or used as data by the server, the server can load and store this data in its zones. Although Windows-based DNS servers are UTF-8 aware, they remain compatible with other DNS servers that use traditional US-ASCII data encoding and current DNS standards.

How the DNS service implements UTF-8

To provide standards compatibility and interoperability with other DNS implementations, the DNS service uses uniform downcasing of any received character data. In this process, the DNS service converts all uppercase characters used in standard US-ASCII data to lowercase equivalent data for the following reasons:

  • To maintain compatibility with current and existing DNS standards.
  • To provide interoperability with DNS server implementations that do not recognize or support UTF-8 encoding.

To understand why uniform downcasing was chosen, several related points must first be considered from the current revised Internet standards for DNS. Several key points in the standards pertain directly to how character data is to be handled between DNS servers and other servers and clients. These include the following:

  • Any binary string can be used in a DNS name. (RFC 2181)
  • DNS servers must be able to compare names in a case-insensitive way. (RFC 1035)
  • The original case for character data should be preserved whenever possible as the data is entered into the system. (RFC 1035)

Because case insensitivity is a required part of the core DNS standard and case preservation is an optional recommendation, uniform downcasing was chosen to provide an effective standards-compliant solution. By downcasing UTF-8 encoded names before transmission, other DNS servers (which are not UTF-8 aware) are able to receive and perform successful binary comparisons of the data and obtain the desired results.

Considerations for interoperability with UTF-8

The DNS Server service can be configured to allow or disallow the use of UTF-8 characters on a per-server basis. Although other DNS server implementations that are not UTF-8 aware might be able to accept the transfer of a zone containing UTF-8 encoded names, these servers might not be able to write back those names to a zone file or reload those names from a zone file. Administrators should exercise caution when transferring a zone containing UTF-8 names to a DNS server that is not UTF-8-aware.

Some protocols place restrictions on the characters allowed in a name. In addition, names that are intended to be globally visible (RFC 1958) should contain ASCII-only characters, as recommended in RFC 1123.

Notes

  • The use of UTF-8 for transformation of Unicode characters is not noticeable for general users. Only where Network Monitor or another similar tool is used to analyze DNS-related traffic over the physical network are UTF-8 encoded characters observable.
  • In addition to DNS server support for the UTF-8 encoding format, the client resolver defaults to using the UTF-8 character encoding format.
  • Names encoded in UTF-8 format must not exceed the size limits clarified in RFC 2181, which specifies a maximum of 63 octets per label and 255 octets per name. Character count is insufficient to determine size because some UTF-8 characters exceed one octet in length.
  • The UTF-8 encoding protocol adapts to use with existing DNS protocol implementations that expect US-ASCII characters because representation of US-ASCII characters in UTF-8 is identical, byte for byte, to the US-ASCII representation. DNS client or server implementations that do not recognize UTF-8 characters always encode names in the US-ASCII format. Those names are correctly interpreted by the DNS Server service.
  • The DNS service provides the ability to configure name checking to allow or restrict the use of UTF-8 characters in DNS data. For more information, see To change the name-checking method used by the DNS server.

    By default, multibyte UTF-8 name checking is used, allowing the greatest tolerance when the DNS service processes characters. This is the preferred name-checking method for most privately operated DNS servers that are not providing name service for Internet hosts.

  • XOX


WINS lookup integration

Support for using Windows Internet Name Service (WINS) is provided to look up DNS names that cannot be resolved by querying the DNS domain namespace. To accomplish WINS lookup, two specific resource record types are used and can be enabled for any zones loaded by the DNS service:

  • The WINS resource record, which can be enabled to integrate WINS lookup into forward lookup zones
  • The WINS-R resource record, which can be enabled to integrate node adapter status request for reverse lookup zones

The WINS resource record

The WINS and DNS services are used to provide name resolution for the NetBIOS namespace and the DNS domain namespace, respectively. Although both DNS and WINS can provide a separate and useful name service to clients, WINS is mainly needed to provide support for older clients and programs that require support for NetBIOS naming.

However, the DNS service can work with WINS to provide combined name searches in both namespaces when resolving a DNS domain name not found in zone information. To provide this interoperability, a new record (the WINS record) was defined as part of the zone database file.

The WINS resource record is specific to computers running Windows NT 4.0 and earlier, Windows 2000, and Windows Server 2003 operating systems and can be attached only to the domain of origin for a zone. The presence of a WINS resource record can instruct the DNS service to use WINS to look up any forward queries for host names or names that are not found in the zone database. This functionality is particularly useful for name resolution required by clients that are not WINS-aware (for example, UNIX) for the names of computers not registered with DNS, such as Windows 95 or Windows 98 computers.

How WINS lookup works

The following is an example of a DNS client (host-b) querying its DNS server in an attempt to look up the address for another computer named host-a.example.microsoft.com..

Example of WINS lookup integration with DNS

In Step 1, the client queries its preferred DNS server. In Steps 2 through 8, the normal process of recursion proceeds as the preferred DNS server queries other DNS servers in succession on behalf of the client. This process concludes at Step 8, when the DNS server for the example.microsoft.com zone is located through the previous chain of referral answers. At this point in the process, the server contacted is a DNS server either running Windows NT Server 4.0, Windows 2000, or Windows Server 2003.

When the DNS server for the example.microsoft.com zone receives the query for host-a, it looks in its configured zone to see if a matching address (A) resource record (RR) can be found. If no A record is found and the zone is enabled to use WINS lookup, the server does the following:

  • The DNS server separates the host part of the name (host-a) from the fully qualified domain name contained in the DNS query.

    The host part of the name is the first label in the queried DNS domain name before a period is used in the name.

  • The server then sends a NetBIOS name request to the WINS server using the host name, host-a.
  • If the WINS server can resolve the name, it returns the IP address to the DNS server.
  • The DNS server then compiles an A resource record using the IP address resolved through the WINS server and returns this record to the original preferred DNS server that was queried by the requesting client, host-b.
  • The preferred DNS server then passes the query answer back to the requesting client.

How WINS reverse lookup works

There is also a WINS-R record or WINS reverse lookup entry that can be enabled and added to reverse lookup zones. However, because the WINS database is not indexed by IP address, the DNS service cannot send a reverse name lookup to WINS to get the name of a computer given its IP address.

Because WINS does not provide reverse lookup capability, the DNS service instead sends a node adapter status request directly to the IP address implied in the DNS reverse query. When the DNS server gets the NetBIOS name from the node status response, it appends the DNS domain name back onto the NetBIOS name provided in the node status response and forwards the result to the requesting client.

Note

  • The WINS and WINS-R resource records are proprietary to the DNS Server service provided by Windows. You can prevent these resource records from being included in zone transfers to other DNS server implementations. For more information, see Using WINS lookup.


Deploying DNS

This section covers:

  • Namespace planning for DNS
  • Zone planning for DNS
  • Server planning for DNS
  • Migrating servers
  • Interoperability issues
  • Securing DNS deployment


Namespace planning for DNS

Before you begin using DNS on your network, decide on a plan for your DNS domain namespace. Coming up with a namespace plan involves making some decisions about how you intend to use DNS naming and what goals you are trying to accomplish in using DNS. Some questions you might have at this stage include the following:

  • Have you previously chosen and registered a DNS domain name for use on the Internet?
  • Are you going to set up DNS servers on a private network or the Internet?
  • Are you going to use DNS to support your use of Active Directory?
  • What naming requirements do you need to follow when choosing DNS domain names for computers?

Each of these questions is further discussed in the following sections.

Choosing your first DNS domain name

When setting up DNS servers, it is recommended that you first choose and register a unique parent DNS domain name that can be used for hosting your organization on the Internet, for example, "microsoft.com". This name is a second-level domain within one of the top-level domains used on the Internet. For a list and description of the most common top-level domains used on the Internet, see Top-level domains.

Once you have chosen your parent domain name, you can combine this name with a location or organizational name used within your organization to form other subdomain names. For example, if a subdomain were added, such as the itg.example.microsoft.com domain tree (for resources used by the information technology group at your organization), additional subdomain names could be formed using this name. For instance, a group of programmers working on electronic data interchange (EDI) in this division could have a subdomain named edi.itg.example.microsoft.com. Likewise, another group of workers providing support in this division might use support.itg.example.microsoft.com.

Before you decide on a parent DNS domain name for your organization to use on the Internet, perform a search to see if the name is already registered to another organization or person. The Internet DNS namespace is currently managed by the Internet Network Information Center (InterNIC). In the future, other domain name registrars might also be available.

For more information, see Using DNS on the Internet.

DNS namespace planning for Active Directory

If you are using Active Directory, you need to first establish a namespace plan. Before a DNS domain namespace can be properly implemented, the Active Directory structure needs to be available. Therefore, begin with the Active Directory design and support it with the appropriate DNS namespace. Upon review, if you detect unforeseen or undesirable consequences for either of your plans, make revisions as needed.

Active Directory domains are named with DNS names. When choosing DNS names to use for your Active Directory domains, start with the registered DNS domain name suffix that your organization has reserved for use on the Internet, such as microsoft.com and combine this name with either geographical or divisional names used in your organization to form full names for your Active Directory domains.

For example, the test group at Microsoft might call their domain test.example.microsoft.com. This method of naming ensures that each Active Directory domain name is globally unique. And, once employed, this naming method also makes it easy to use existing names as parents for creating additional subdomains and further grow the namespace to accommodate new departments within your organization.

For a small organization using only a single domain or a small multidomain model, planning can be straightforward and follow an approach similar to the previous examples. For a larger organization using a more complex domain model, refer to additional Microsoft resources. For more information, see Microsoft Windows Deployment and Resource Kits.

Caution

  • When planning your DNS and Active Directory namespace, it is recommended that you use a differing set of distinguished names that do not overlap as the basis for your internal and external DNS use. As an example, assuming your organization's parent domain name is "example.microsoft.com"
    • For internal DNS names usage you could use a name such as "internal.example.microsoft.com"
    • For external DNS names usage you could use a name such as "external.example.microsoft.com"

    By keeping your internal and external namespaces separate and distinct in this way, you enable simplified maintenance of configurations such as domain name filter or exclusion lists.

Choosing names

It is strongly recommended that you use only characters in your names that are part of the Internet standard character set permitted for use in DNS host naming. Allowed characters are defined in Request for Comments (RFC) 1123 as follows: all uppercase letters (A-Z), lowercase letters (a-z), numbers (0-9), and the hyphen (-).

For organizations with a prior investment in Microsoft NetBIOS technology, existing computer names might conform to the NetBIOS naming standard. If this is the case, consider revising the names of your computers to the Internet DNS standard.

The process of adjusting your naming conventions might prove to be time consuming. To ease the transition from NetBIOS names to DNS domain names, the DNS Server service includes support for extended ASCII and Unicode characters. However, this additional character support can only be used in a network environment with computers running Windows 2000 or a product in the Windows Server 2003 family. This is because most other DNS resolver client software is based on RFC 1123, the specification that standardizes Internet host naming requirements. If a nonstandard DNS domain name is entered during setup, a warning message appears recommending that a standard DNS name be used instead.

In networks running Windows NT 4.0 and earlier, a NetBIOS name is used to identify a computer running a Windows operating system. In networks with computers running Windows 2000 or a product in the Windows Server 2003 family, a computer can be identified in any of the following ways:

  • A NetBIOS computer name, which is optional and is used for interoperability with earlier Windows systems.
  • The full computer name. This is the default name for the computer.

In addition to these, a computer might also be identified by the FQDN comprised of the computer (host) name and a connection-specific domain name, where one is configured and applied for a specific network connection on the computer.

The full computer name is a concatenation of both the computer name and the primary DNS suffix for the computer. The DNS domain name for the computer is part of the System properties for the computer and is not related to any specifically installed networking components. However, computers that do not use either networking or TCP/IP do not have a DNS domain name.

The following table is a comparison of NetBIOS and DNS computer names.

Restriction | DNS in Windows NT 4.0 (standard DNS) | DNS in Windows 2000 and the Windows Server 2003 family | NetBIOS
Characters | Supports RFC 1123, which allows all uppercase letters (A-Z), lowercase letters (a-z), numbers (0-9), and the hyphen (-). | Supports RFC 1123 and UTF-8. You can configure the DNS server to allow or disallow the use of UTF-8 characters. You can do so on a per-server basis. For more information, see Unicode character support. | Not allowed: Unicode characters, numbers, white space, symbols: / \ [ ] : | < > + = ; , ? and *
Host name and FQDN length. | 63 octets per label. 255 bytes per FQDN (254 bytes for the FQDN plus one byte for the terminating dot). | The same as standard DNS with the addition of UTF-8 support. Character count is insufficient to determine size because some UTF-8 characters exceed one octet in length. Domain controllers are limited to 155 bytes for an FQDN. Domain controllers are limited to 155 bytes for an FQDN. | 15 bytes in length.

To ensure interoperability between NetBIOS and DNS naming in Windows, a new naming parameter called the NetBIOS computer name was introduced. The value of this parameter, which is not required in a Windows 2000 or Windows Server 2003 environment, is derived from the first 15 characters of the DNS full computer name.

When the full computer name is a combination of the computer name and the primary DNS suffix for the computer, the impact of renaming and making the transition from a NetBIOS namespace to a DNS namespace can be minimal. Users continue to focus on the short computer name. If this name is 15 characters or less, it can be made identical to the NetBIOS computer name. The administrator can then also assign a DNS domain name for each computer. This can be done using remote administration tools.

In this way, the System properties page can have the following settings on the Computer Name tab (or its related dialog boxes):

Computer name | longer-than-15characters-name
NetBIOS computer name | longer-than-15c
Primary DNS suffix for this computer | example.microsoft.com

Important

  • By default, the primary DNS suffix portion of a computer's fully qualified domain name (FQDN) must be the same as the name of the Active Directory domain where the computer is located. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces or the Lightweight Directory Access Protocol (LDAP).

    • For more information, see Programming interfaces and Directory access protocol.

Notes

  • In addition to the primary DNS domain name for a computer, connection-specific DNS names can be configured. For more information, see Configuring multiple names.
  • Because DNS host names are encoded in UTF-8 format, they do not necessarily have only 1 byte per character. ASCII characters are 1 byte each, but the size of extended characters is more than 1 byte.
  • Some non-Microsoft resolver software supports only the characters listed in RFC 1123. If you have any non-Microsoft resolver software, that software is probably not able to look up computers with names that have non-standard characters.
  • A DNS server that does not support UTF-8 encoding might accept a zone transfer of a zone containing UTF-8 names, but it cannot write back those names to a zone file or reload those names from a zone file. Therefore, you must not transfer a zone that contains UTF-8 characters to a DNS server that does not support them.

Integration planning: Supporting multiple namespaces

In addition to support for the internal DNS namespace, many networks require support for resolving external DNS names, such as those used on the Internet. The DNS Server service provides ways to integrate and manage disjointed namespaces where both external and internal DNS names are resolved on your network.

In deciding how to integrate namespaces, determine which of the following scenarios most closely resembles your situation and proposed use of DNS:

  • An internal DNS namespace, used only on your own network.
  • An internal DNS namespace with referral and access to an external namespace, such as referral or forwarding to a DNS server on the Internet.
  • An external DNS namespace, used only on a public network such as the Internet.

If you decide to limit the use of DNS as a name service within your private namespace, there are no restrictions on how it is designed or implemented. For example, you can choose any DNS naming standard, configure DNS servers to be valid root servers for your network's DNS distributed design, or form an entirely self-contained DNS domain tree structure and hierarchy.

When you start providing either referral to an external DNS namespace or full DNS service on the Internet, you need to consider compatibility between your private and external namespaces. Additionally, Internet service requires the registration of parent domain names for your organization.

For more information on planning secure integration of Internet DNS names referral through your secured private network, see the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Notes

  • When you add and connect to a DNS server for the first time using the DNS console, the root hints file (Cache.dns) is automatically primed for use on your network. This occurs transparently and does not require that you take any further action for this to be done.

    Depending on how you use DNS, you can update this file in one of the following ways:

    • If you are connected to the Internet, you can either edit or update the local root hints file when the Internet root hints file (Named.root) is updated and released by the owners of the Internet root zone. For a current copy of this file, you can use anonymous FTP to the InterNIC Web site.
    • If you are not connected to the Internet, you can remove the default resource records contained in this file and replace them with NS and A resource records for the DNS authoritative servers at the root domain of your site. For root domain servers on your private network, you can safely remove this file entirely because servers operating at this domain level do not require or use a cache of root hints.
  • If you delete the Cache.dns file for a private root domain server when you have configured the DNS Server service using the From file method, you also need to remove the cache directive from the server boot file before restarting the DNS Server service.
  • XOX


Zone planning for DNS

When first partitioning your namespace into zones, review traffic patterns in your current or proposed network. Although DNS is designed to help reduce broadcast traffic between local subnets, it does create some traffic between servers and clients that should be reviewed. This is particularly true in cases where DNS is used on routed networks.

To review DNS traffic, you can use DNS server statistics or the DNS performance counters provided with System Monitor. For more information, see Verifying server configuration or Monitoring DNS server performance.

In addition to routing traffic, consider the impact of the following common types of DNS-related communication, especially when you are operating across slow-speed links on a wide area network:

  • Server-to-server traffic caused both by zone transfers with other DNS servers and by DNS interoperability with other servers (for example, when WINS lookup is enabled).
  • Client-to-server traffic caused by both query loads and dynamic updates sent by DNS client computers or DHCP servers providing dynamic updating for earlier-version DNS clients that do not support dynamic updates.

For small, flat namespaces, you might use full replication of all DNS zones to all DNS servers in your network. For large, vertical namespaces, this is neither possible nor recommended. In larger networks, it is often necessary to study, test, analyze, and revise your zone plans based on observed or estimated traffic patterns. After careful analysis, you can partition and delegate your DNS zones based on what is required for providing efficient and fault-tolerant name service to each location or site.

Notes

  • If you are using a mixture of Windows DNS servers, be aware that zone transfers can sometimes be slow between the DNS Server service and some other DNS server implementations. For more information, see Zone transfer with BIND and other DNS server implementations .
  • The DNS Server service supports incremental zone transfers between servers replicating a standard zone. This feature can reduce DNS replication traffic considerations and should be reviewed in zone planning. For more information, see Understanding zones and zone transfer.
  • Although it is useful to plan zones, you might also want to explore the use of caching-only servers, which do not host DNS zones. Caching-only servers are a good option at small remote sites that have a stable and minimal use for DNS name service but are located across a WAN where the transfer of a large zone over a slower link can be resource-intensive. For more information, see Using caching-only servers.


Server planning for DNS

When planning for your DNS servers, it is important to consider the following:

  • Perform capacity planning and review server hardware requirements.
  • Determine how many DNS servers you need and their role in your network.

    When deciding the number of DNS servers to use, decide which servers will host primary and secondary copies of zones. Also, if you are using Active Directory, determine whether the server computer will perform as a domain controller or a member server for the domain.

  • Decide where you are going to place DNS servers on your network for traffic loads, replication, and fault tolerance.
  • Decide whether to use only DNS servers running Windows Server 2003 for all your DNS servers or if you are operating a mixture of Windows and other DNS server implementations.

    For more information about migration and interoperability of the DNS Server service with other DNS server implementations, see Migrating servers or Interoperability issues.

Server capacity planning

Planning and deploying DNS servers on your network involves examining several aspects of your network and the capacity requirements for any DNS servers you intend to use in it. Some questions to consider when planning include the following:

  • How many zones is the DNS server expected to load and host?
  • For each zone the server is loading for service, how large is the zone (based on the size of the zone file or the number of resource records used in the zone)?
  • For a multihomed DNS server, how many interfaces are to be enabled for listening to and servicing DNS clients on each of the server's connected subnets?
  • How many total or overall DNS query requests from all of its clients is a DNS server expected to receive and service?

In many cases, adding more RAM to a DNS server can provide the most noticeable improvements in performance. This is because the DNS Server service fully loads all of its configured zones into memory at startup. If your server is operating and loading a large number of zones, and dynamic updates occur frequently for zone clients, additional memory can be helpful.

Keep in mind that for typical usage, the DNS server consumes system memory as follows:

  • Approximately 4 MB of RAM is used when the DNS server is started without any zones.
  • For each addition of zones or resource records to the server, the DNS server consumes additional server memory.
  • It is estimated that for the addition of every resource record to a server zone, an average of approximately 100 bytes of server memory is used.

    For example, if a zone containing 1000 resource records is added to a server, it would require approximately 100 KB (kilobytes) of server memory.

In determining your DNS server plans, you can start by reviewing sample DNS server performance test results collected by the DNS development and testing teams. In addition, you can use DNS server-related counters provided for use with monitoring tools to obtain your own performance measurements. For more information, see Monitoring DNS server performance.

Important

  • The previous recommendations are not intended to indicate maximum performance or limitations for DNS servers.
  • These numbers are approximate and can be influenced by the type of resource records entered in zones, the number of resource records with the same owner name, and the number of zones in use at a specific DNS server.

Where to place DNS servers

In general, place your DNS servers at a location on your network that is centrally accessible to your clients. It is often most practical to use a DNS server on each subnet. There are several factors to consider when deciding where a DNS server is needed:
  • If you are deploying DNS to support Active Directory, is the DNS server computer also a domain controller or likely to be promoted to one in the future?
  • If the DNS server stops responding, are its local clients able to gain access to an alternate DNS server?
  • If the DNS server is located on a subnet that is remote to some of its clients, what other DNS servers or name resolution options are available if the routed connection stops responding?

For DNS server installations where the use of Active Directory is an issue, review special interoperability issues and installation details. For more information, see DNS considerations for Active Directory.

For all DNS server installations including those in which the use of Active Directory is not an issue, the following server placement and planning guidelines can be usefully applied.

For example, if you have a routed local area network and high-speed links that are fairly reliable, you might be able to use one DNS server for a larger, multiple subnetted network area. If you have a high number of client nodes on a single subnet design, you might want to add more than one DNS server to the subnet to provide backup and failover if the preferred DNS server stops responding.

When determining the number of DNS servers you need to use, assess the effect of zone transfers and DNS query traffic on slower links in your network. Although DNS is designed to help reduce broadcast traffic between local subnets, it does create some traffic between servers and clients that should be reviewed, particularly when used in complexly routed LAN or WAN environments.

Consider the effects of zone transfer over slower speed links, like those typically used for a wide area network (WAN) connection. Although the DNS Server service supports incremental zone transfers and DNS clients and servers can cache recently used names, traffic considerations are sometimes still an issue, particularly when DHCP leases are shortened and, as a result, dynamic updates in DNS are performed more frequently. One option for dealing with remote locations on WAN links is to set up a DNS server at these locations to provide caching-only DNS service.

With most installations, you should have at least two server computers hosting each of your DNS zones for fault tolerance. DNS was designed to have two servers for each zone, one as a primary server and the other as a backup or secondary server. When making any final determinations about the number of servers to use, first assess the level of fault tolerance you need for your network.

Notes

  • When only a single DNS server is used on a small LAN in a single-subnet environment, you can configure the single server to simulate both the primary and secondary servers for a zone.
  • For best results and simplified DNS administration, consider using the Windows Server 2003 DNS Server service for all of your DNS servers.
  • When administering zone files created by the DNS Server service, it is recommended that you use the DNS console tool to make changes. As an alternate option, it is possible to administer all of your DNS zone files manually using any application that supports file saving in text mode. Whether you decide to edit zone files manually in a text editor or use the DNS console to modify them, select one method for updating zones and use it consistently. This helps prevent having zone edits overwritten or rejected, which might happen if you change from one method to another.


Migrating servers

DNS migration can occur in one of the following ways:

  1. Upgrading a computer running the version of DNS included in Windows NT Server 4.0 or Windows 2000 to a server running Windows Server 2003.
  2. Moving zone files from an existing DNS server running another DNS server implementation, such as server running a version of the Berkeley Internet Name Domain (BIND) software.
  3. Migrating zones using master-secondary zone transfer from BIND servers to DNS servers running Windows Server 2003.

Upgrading DNS servers from Windows NT Server 4.0 and Windows 2000

Any zones or server configuration files and parameters created and stored using the Windows NT Server 4.0 or Windows 2000 version of the DNS Server service are stored in the same system folder locations. There is no conversion of data required during the upgrade process.

Moving BIND-based files

When moving from a BIND DNS server to a DNS server running Windows Server 2003, however, you need to copy any BIND-created zone or boot files that you intend to use with the DNS Server service. Also, if you continue to use a BIND boot file to provide the initial configuration settings used by the DNS Server service when it is started, you need to change the boot method used by the DNS Server service or rename the zone files from the BIND naming convention to that used by DNS servers running under the DNS Server service provided in Windows operating systems. For more information, see To change the boot method used by the DNS server.

Any zone files created and stored on UNIX DNS servers that use BIND need to be manually copied from those servers to the systemroot\System32\Dns folder on the server running Windows Server 2003.

If you do not migrate the BIND boot file or specify the BIND name when creating the zones using the DNS console, then you will need to rename these zones. The following table shows examples of how BIND server files are renamed for use with the DNS Server service that is provided on servers running a member of the Windows Server 2003 family.

Description | UNIX file name | Windows Server 2003 file name
Boot file | named.boot | Boot
Forward lookup zone file | db.domain_name | domain_name.dns
Reverse lookup zone file | db.IP_network_forward_notation | IP_network_reverse_notation.dns

For a reverse lookup zone, BIND uses a convention of noting reverse domain names as a forward notation of mapped IP network, such as db.192.1.168 for a reverse lookup zone created for an example IP network address of 192.168.1.0. DNS servers running Windows Server 2003, however, use the fully qualified domain name (FQDN) for the zone, which includes the in-addr.arpa domain, to complete the file name. In this example, the correct name to use for the same zone in Windows Server 2003 DNS is 168.1.192.in-addr.arpa.dns when copying and renaming the file.

Notes

  • If you are using the BIND boot file with the DNS Server service after migration, there are other limitations that apply to the use of this file by the DNS Server service. For example, some BIND boot directives are not supported — in particular, xfrnets and other directives provided with versions of BIND, such as version 8.1.1 or later. For more information, see articles Q194513, "The Structure of a Domain Name System Boot File"; Q234144, "DNS Boot File Directives and Configuration for Windows NT 4.0," in the Microsoft Knowledge Base. (http://www.microsoft.com/)
  • If you are accustomed to manually editing DNS zone files, be aware that the DNS Server service uses RFC-compliant notation for its supported resource records (RRs). In most cases, the DNS Server service interprets and loads RRs from zone files originally created for BIND DNS servers without any need for file changes. If, however, you have used non-standard record formatting, the DNS Server service can detect these edits and interpret them as bad or errored zone data. For more information about RFCs, see DNS RFCs.

Migrating from third-party servers using zone transfer

Another possible scenario for server migration is using zone transfer to migrate third-party server zones to DNS servers running Windows Server 2003. To accomplish this, you can take the following steps:

  1. At your server running Windows Server 2003, install the DNS Server service.
  2. Using the DNS console, at the new server add secondary zones for all of your existing zones hosted at the BIND-based DNS servers.

    Configure the third-party servers as the master servers for each of the secondary zones you need to create.

  3. After completing the zone transfers, convert any of the secondary zones to primary zones for the zones that were obtained from primary zones at the third-party servers.
  4. Configure the previous primary servers to be secondary servers for the migrated zones or demote the previous primary servers.
  5. For the other secondary zones that remain, update the master servers for those zones to use the new primary DNS servers running Windows Server 2003.

For more information, see To install a DNS server, To add a secondary server for an existing zone, To initiate a zone transfer at a secondary server, To change the zone type, and To update the master server for a secondary zone.

Note

  • If you choose to continue to use your third-party DNS servers as secondary servers for zones for which your DNS server running Windows Server 2003 is the primary server, you should review interoperability issues related to zone transfer for this configuration. For more information, see Zone transfer with BIND and other DNS server implementations.


Interoperability issues

DNS servers running Windows Server 2003 are compliant with most of the Request for Comments (RFC) specifications used to define the DNS protocol. This provides clear benefits for operating DNS servers in mixed or heterogeneous environments. For more information about RFCs, see DNS RFCs.

The primary benefits for interoperability in these environments include:

  • Full interoperability with other DNS server implementations that implement RFC-compliant behavior for DNS name service.
  • Use of Windows DNS servers to provide DNS service on the Internet.

For interoperability testing, the Windows Server 2003 DNS development team has tested Windows Server 2003 DNS Server and Client services with the following versions of the Berkeley Internet Name Domain (BIND) DNS server implementation:

  • BIND 4.9.7
  • BIND 8.1.2
  • BIND 8.2
  • BIND 9.1.0

Interoperability and configuration issues related to using Windows Server 2003 DNS with other various environments, or when using DNS servers on the Internet, are covered in the following sections.

DNS considerations for Active Directory

DNS is required for network resources to locate Active Directory domain controllers. You can elect to set up the DNS Server service as part of the installation of Active Directory using the Active Directory Installation Wizard. When you install Active Directory on a server, the server is promoted to the role of a domain controller.

When you install Active Directory on a server, the Active Directory Installation Wizard provides the option to automatically install the DNS Server service and add new zones locally. When you select the option to install and configure a DNS server using the Active Directory Installation Wizard, zones are created based on the DNS name you have specified in the wizard.

A simple method of redundancy and fault tolerance planning is to have a DNS server running on each domain controller. For each subnet, have two domain controllers running the DNS Server service and hosting Active Directory–integrated zones.

Zone transfer with BIND and other DNS server implementations

When transferring a zone between two Windows DNS servers, the DNS Server service always uses a fast transfer method that uses compression. This method includes multiple resource records (RRs) in each message sent to complete the transfer of the zone between servers. For DNS servers running Windows Server 2003, this is the default method used when initiating transfer with other DNS server implementations.

If necessary, DNS servers running Windows Server 2003 can be configured to transfer a zone using the slower uncompressed transfer format. This enables successful zone transfers to be made with DNS servers that do not support the faster transfer method, such as BIND servers prior to version 4.9.4.

When you select the Bind Secondaries check box in advanced server properties, no fast transfers are made. By default, the check box is cleared to enable fast transfers. For more information, see To enable or disable fast transfer format during zone transfers.

Supporting Active Directory with other DNS server implementations

In many large organizations, DNS is already implemented using other solutions, such as UNIX DNS servers that run legacy versions of BIND software. In some cases, these DNS servers are not equipped to support the DNS requirements for deploying Active Directory. This issue can be addressed in one of two ways:

  • Upgrade any BIND DNS servers to version 8.1.2 or later of the BIND software to meet the DNS requirements for Active Directory support.
  • Use the DNS Server service provided with Windows Server 2003 family, migrating, if possible, any of your current DNS zones to DNS servers running Windows Server 2003.

Although the DNS Server service is recommended to support Active Directory, you can use other DNS server implementations for this purpose. These other implementations should, however, support the following standard specifications:

  • The service location (SRV) resource record, as described in the Internet draft, "A DNS RR for specifying the location of services (DNS SRV)."
  • Dynamic updates in DNS, as described in RFC 2136.

Support for dynamic updates is recommended but not essential. Support for the SRV resource record is mandatory because it is required to provide basic DNS support to Active Directory. For example, a DNS server that does not support dynamic updates, like that provided with Windows NT Server 4.0 (updated to Service Pack 4 or later) supports the DNS requirements of Active Directory because SRV resource record support was added with Service Pack 4.

Additional manual administration of SRV resource records is needed for DNS configuration support of Active Directory to function properly on a DNS server that does not support dynamic updates. For more information, see Service location (SRV) resource records.

Interoperating Windows DNS servers with other DNS server implementations

If you decide to use the Windows DNS Server service and manage it with a split DNS configuration in which:

  • Existing DNS servers for root zones are not to be upgraded or migrated to other DNS solutions.
  • Windows Server 2003 DNS is to be deployed and is to provide management of any DNS domain names required to register, update, and support for use with Active Directory.

You can modify your DNS namespace design plans in either of the following ways:

  1. Create a single new subdomain in your current DNS domain namespace to root your first Active Directory domain.

    For example, if your organization has registered and is using a second-level domain name, such as microsoft.com, you can create a single subdomain such as example.microsoft.com and use this domain to root the DNS domain namespace used by Active Directory. The DNS Server service is automatically configured to support Active Directory when you install the first domain controller.

    Before you have created a zone for the new subdomain at a computer running the DNS Server service, you can delegate these subdomains away at the primary zone for your second-level domain, such as "microsoft.com." In some cases, you might only need to notify another DNS or UNIX system administrator in your organization to make the delegation for you. For more information, see Delegating zones.

  2. Create multiple subdomains based on your DNS second-level domain to support registration of Active Directory in DNS.

    For example, if your organization has a registered second-level DNS domain name already in use (such as microsoft.com), you can create additional subdomains that are delegated to Windows DNS servers and used only for registering DNS names related to Active Directory.

    This method is more complex to implement, but enables less change to your currently deployed DNS infrastructure that is not Windows-based. With this namespace design, you create only those additional subdomains and appropriate zones needed to support your Active Directory deployment. For example, in this configuration, the domain name microsoft.com is both the root DNS and the root Active Directory domain name for your organization.

    For this configuration, you first need to create zones for the following subdomains using the DNS Microsoft Management Console (MMC) console on a DNS server running Windows Server 2003:

    child1.microsoft.com
    child2.microsoft.com

    Before these zones are created, you can delegate these subdomains away at the primary zone for your parent or second-level domain name or notify another DNS administrator who manages these zones for your organization to do so. For more information, see Delegating zones.

Using DNS on the Internet

To establish a presence on the Internet, an individual or business must first apply for and register a second-level domain name with an authorized DNS domain name registration authority. Your Internet service provider (ISP) can often perform this function and obtain a name on your behalf, usually for an additional fee.

To register your domain name, there are several required tasks, including:

  • Selecting and researching a second-level domain name that is not currently registered or in use.

    This can easily be done if you have Internet access by using a WHOIS query engine provided at the Web site for your applicable Internet DNS domain name registrar. Be prepared to select an alternate name if your WHOIS query indicates that your preferred selection is already registered and in use.

  • Registering and obtaining at least one IP address valid for use on the Internet.

    This address is needed for the DNS server on the Internet that you want to establish as the host for the primary copy of the zone based on your second-level domain name. In many cases, if you are using an ISP to register a domain name on your behalf, they can specify the IP addresses for one or two of their servers as primary and secondary for the Internet.

    As part of the registration process, an applicant must provide at least two currently active DNS servers that are used on the Internet as the primary and secondary servers designated for the new domain. This requirement is necessary to ensure proper Internet root server configuration and referral for others that query for your registered DNS domain name on the Internet.

    After one IP address has been obtained, you can sometimes arrange (or your ISP can do so on your behalf) to use another company or ISP's DNS server as a secondary server for the zone. If you still need to obtain an IP address directly for use in the United States, a valid IP address can be obtained through the American Registry for Internet Numbers (ARIN). In other countries or regions, you might contact your local Internet service or telephony provider to find out how to register and acquire an IP address if one is needed.

  • Complete the registration application form and submit it with your registration fee to the appropriate Internet DNS domain name registration authority. Registrations are typically in force for a finite period of time and must be periodically renewed.

For more information about selecting and registering your Internet DNS name, see the VeriSign Global Registry Services Web site.

Interoperability planning: Configuring related services

Windows Server 2003 DNS provides several interoperability options with other TCP/IP services. The following options can be used to reduce the amount of time you need to spend administering your DNS infrastructure:

  • WINS forward and reverse lookups.

    The DNS Server service provides for the use of WINS lookup. This feature enables configured DNS zones to refer queries not answered from current zone information to a WINS server for further resolution. With this added search of the WINS namespace, both DNS and WINS are used to complete a full search of registered names for a matched response.

    WINS lookup is supported for both forward and reverse lookup zones and can be enabled on a per-zone basis or configured for selected zones. This feature should also be configured to prevent replication or zone transfer of WINS resource records to servers with other DNS implementations that do not recognize the WINS resource records.

  • Dynamic integration with DHCP servers.

    For Windows Server 2003 DNS, the DHCP service provides default support to register and update information for legacy DHCP clients in DNS zones. Legacy clients typically include other Microsoft TCP/IP client computers that were released prior to Windows 2000. The Windows Server 2003 DNS-DHCP integration enables a DHCP client that is unable to dynamically update DNS resource records directly to have this information updated in DNS forward and reverse lookup zones by the DHCP server.

Notes

  • XOX
  • Dynamic integration with the DHCP service is only available on DNS servers running Windows 2000 and Windows Server 2003. DNS-DHCP integration is not supported by DHCP servers running under Windows NT Server 4.0 and earlier.
  • By default, a zone hosted on a DNS server running Windows Server 2003 will only allow a zone transfer to authoritative DNS servers listed in the name server (NS) resource records for the zone.


Securing DNS deployment

When designing your DNS server deployment, use the following DNS security guidelines:

  • If your network hosts are not required to resolve names on the Internet, eliminate DNS communication with the Internet. In this DNS design, you can use a private DNS namespace that is hosted entirely in your network. The private DNS namespace is distributed just as the Internet DNS namespace, with your internal DNS servers hosting zones for the root domain and top-level domains.
  • Split the DNS namespace for your organization between internal DNS servers behind the firewall and external DNS servers in front of the firewall. In this DNS design, your internal DNS namespace is a subdomain of your external DNS namespace. For example, if the Internet DNS namespace for your organization is adatum.com, then the internal DNS namespace for your network is corp.adatum.com.
  • Host your internal DNS namespace on internal DNS servers and host your external DNS namespace on external DNS servers exposed to the Internet. To resolves queries for external names made by internal hosts, the internal DNS servers forward queries for external names to the external DNS servers. External hosts use only the external DNS servers for Internet name resolution.
  • Configure your packet-filtering firewall to only allow UDP and TCP port 53 communication between your external DNS server and a single internal DNS server. This will facilitate communication between internal and external DNS servers and prevent any other external computer from gaining access to your internal DNS namespace.

For more information, see Security information for DNS.


Administering DNS

This section covers:

  • Managing servers
  • Managing clients
  • Managing zones
  • Monitoring and optimizing servers


Managing servers

This section covers:

  • Configuring a new primary server
  • Updating existing servers
  • Using secondary servers
  • Securing the DNS Server service
  • Using caching-only servers
  • Modifying server defaults
  • Managing the aging and scavenging of server data
  • Using forwarders
  • Directing queries through forwarders
  • Updating root hints
  • Configuring multihomed servers
  • Server administration using Dnscmd


Configuring a new primary server

There are several situations in which you might add and configure a new DNS server for your network:

  • When you are adding a new DNS server to your network and configuring a new zone for first-time use.
  • When you have already created a zone at another DNS server and are adding a new server that also needs to load and provide service for the zone.
  • When you already have a DNS server configured with a zone or zones, but need to add a new zone for another domain name, such as a subdomain.

For first-time configuration of a new server and zone, it is best to use the checklists provided with DNS Help to begin your DNS deployment. If you are going to deploy a DNS server without using Active Directory, use Checklist: Deploying DNS. For deploying DNS to support your use of Active Directory, use Checklist: Deploying DNS for Active Directory.

Adding a primary DNS server for an existing zone

The primary DNS server for a zone acts as the point of update for the zone. Newly created zones are always this type. You can use primary zones in one of two ways: as standard primary zones or primary zones integrated with Active Directory.

For standard primary–type zones, only a single DNS server can host and load the master copy of the zone. If you create a zone and keep it as a standard primary zone, no additional primary servers for the zone are permitted. Only one server is allowed to accept dynamic updates and process zone changes.

The standard primary model implies a single point of failure. For example, if for any reason the primary server for a zone is unavailable to the network, no dynamic updates to the zone can be made. Note that queries for names in the zone are not affected and can continue uninterrupted, as long as secondary servers for the zone are available to answer them.

You can add more primary servers for a zone by using the directory-integrated storage and replication features of the DNS Server service. To do this, you need to change a zone and integrate it into Active Directory.

You can integrate an existing zone into Active Directory by changing the type of a zone at the originating primary server where it was first created. Once the zone type is changed from Standard primary to Active Directory–integrated, you can add the zone to other DNS servers by configuring them to use the From Active Directory or registry option when they initialize DNS Server service.

When the From Active Directory or registry option is selected, other DNS servers operating as part of the Active Directory domain namespace — such as domain controllers for the Active Directory domain — can query the directory and automatically load all directory-integrated zones, which are stored in the directory database. No other steps are necessary. With the From Active Directory or registry option, any DNS servers operating as part of Active Directory are, by default, also primary servers for directory-integrated zones.

For more information on changing the zone type, see To change the zone type. For more information on changing the server boot method, see To change the boot method used by the DNS server.

Note

  • When using standard primary–type zones, other DNS servers should never be configured to act as primary servers for an existing zone. This design is not supported and might cause errors or inconsistencies in zone data between servers loading different versions of the same zone.

Adding a new primary zone to an existing server

Adding a new primary zone to an existing server can be done whenever additional domains or subdomains are needed in your DNS domain namespace. For example, you might have a zone for a second-level domain such as microsoft.com and want to add a primary zone for the new subdomain, example.microsoft.com.

In this example, you can create the new zone for the subdomain by using the DNS console and running the New Zone Wizard. When you are done, you need to create a delegation in the parent zone for the new subdomain (such as the microsoft.com zone) to complete the addition of the new subdomain and its primary zone.

Once the new primary zone is added, you can perform other zone configuration tasks as needed to fully configure the zone for use. For more information, see Managing zones.


Update existing servers

Updating the configuration of your DNS servers can be necessary for various reasons, such as to:

  • Change the computer (host) name of the server computer.
  • Change the primary or parent DNS domain name of the server computer.
  • Change the IP address for the server computer.
  • Remove a DNS server from the network.
  • Change the primary server for a zone (standard primary zones only).

Each of these is covered in the following sections.

Changing the computer (host) name of the server

If you need to change the host name of a DNS server (but not its parent or primary DNS domain name), make the following changes in the zone where the server is configured as an authoritative server for the zone:

  1. Change the computer name for the server in System properties.
  2. Restart the computer to initiate the following DNS dynamic updates:
    1. Add the new host (A) and pointer (PTR) resource records (RRs) for the new name and IP address of the server.
    2. Remove the old A and PTR RRs for the old name and IP address of the server.
  3. Update the name server (NS) RR in zones where the server is configured as authoritative to point to the new A RR added in step 2.
  4. If the server is the primary server for a standard zone, revise the name in the owner field of the start of authority (SOA) RR for the zone (If the zone is directory-integrated, this step is not needed).
  5. Check in the zones to ensure that any delegation records — NS or A RRs — that are used, are updated for the new name of the server.

Changing the primary DNS domain name of the server

When changing the DNS domain name of a computer, the ability to change the primary DNS domain name of the server can depend on whether or not you are using the computer as a domain controller.

Important

  • By default, the primary DNS suffix portion of a computer's fully qualified domain name (FQDN) must be the same as the name of the Active Directory domain where the computer is located. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces or Lightweight Directory Access Protocol (LDAP).

    • For more information, see Programming interfaces and Directory access protocol.

If you are running the server computer as a domain controller, the primary DNS domain name of the server computer is set to be the same as the name of the Active Directory domain where the server was promoted to be a domain controller. To change this name, you must first demote the server so that it is no longer a domain controller. For a server changing its parent DNS domain name in this situation, the process of adding and deleting A and PTR RRs for the server is done automatically when joining and leaving an Active Directory domain. In this case, only manual updating of the name server (NS) RRs for the old and new DNS parent domains might be needed.

To change the DNS domain name for a DNS server computer not using Active Directory, such as a domain member server or a stand-alone server, some additional changes and manual administration might be necessary. For example, if the old and new DNS domain names are in two different zones, such as Zone A (the old zone) and Zone B (the new zone), you would need to make the following changes:

  1. Change the Primary DNS suffix for this computer in System properties and restart the computer.
  2. In Zone A, remove the host (A) RR for the server.
  3. In Zone B, add the A RR for the server.
  4. Update all start of authority (SOA) and name server (NS) RRs in zones containing the name of the renamed DNS server.

Changing the IP address of the server

To change the IP address for an existing DNS server, the process is the same as for any DNS host computer. Update the IP address in the server address (A) resource record. If the name of the server does not change, NS and SOA records are not affected.

A common configuration error that occurs when changing an IP address in the A resource record in a zone is that the same information used elsewhere in DNS is not updated. For example, if a DNS server that has a name or address change is used in a parent zone as part of a set of delegation records, the zone records might be updated but the delegation records left unchanged. For this reason, it is good to check the parent zone as well when changing or updating IP addresses for A resource records for DNS servers in a zone. Otherwise, zone delegation can fail.

Also, if you are using a multihomed server, be aware of the events and conditions under which a server running Windows Server 2003 can initiate a dynamic update when connection-specific DNS domain naming is used. For more information, see Configuring multiple names.

Removing a DNS server from the network

To remove a DNS server from the network, make the following changes in zones where the server is configured as an authoritative server for the zone:

  1. Remove the address (A) resource record for the server.
  2. Update the name server (NS) records in zones where the server is configured as authoritative to no longer include the server by name (as it appeared in the A record deleted in Step 1).
  3. If the server is the primary server for a standard zone, revise the owner field of the SOA resource record for the zone to point to the new primary DNS server for the zone. (If the zone is directory-integrated, this step is not needed.)
  4. Check the parent zone to ensure that any records (NS or A resource records) used for delegation to the zone are revised and no longer point to the removed server.

Changing the primary server for a zone (standard primary zones only)

For standard primary zones, it can sometimes be necessary to change the designated primary server for a zone. For example, suppose that the current primary server for a standard primary zone is Server A, and the new primary server for the zone is Server B.

To affect the changeover in status from Server A to Server B, make the following zone changes:

  1. Add a new host (A) resource record (RR) for Server B.
  2. Update the name server (NS) RR in the zone to remove Server A and include Server B as a configured server of authority that points to the new A RR added in Step 1.
  3. Revise the name in the owner field of the start of authority (SOA) RR for the zone from Server A to Server B.
  4. Remove the old A RR for Server A.
  5. Check the parent zone to ensure that any delegation records (NS or A RRs) used are updated to refer to Server B.


Using secondary servers

DNS design specifications recommend that at least two DNS servers be used to host each zone. For standard primary–type zones, a secondary server is required to add and configure the zone to appear to other DNS servers in the network. For directory-integrated primary zones, secondary servers are supported but not required for this purpose. For example, two DNS servers running on domain controllers can be redundant primary servers for a zone, providing the same benefits of adding a secondary server while including additional advantages.

Secondary servers can provide a means to offload DNS query traffic in areas of the network where a zone is heavily queried and used. Additionally, if a primary server is down, a secondary server can provide some name resolution in the zone until the primary server is available.

If you add a secondary server, try to locate it as close as possible to clients that have a high demand for names used in the zone. Also, consider placing secondary servers across a router, either on other subnets (if you use a routed LAN) or across WAN links. This provides a good use of a secondary server as a local backup in cases where an intermediate network link becomes the point of failure between DNS servers and clients that use the zone.

Because a primary server always maintains the master copy of updates and changes to the zone, a secondary server relies on DNS zone transfer mechanisms to obtain its information and keep it current. Issues like zone transfer methods — either using full or incremental zone transfers — are more applicable when using secondary servers. For more information, see Understanding zones and zone transfer.

In considering the impact of zone transfers caused by secondary servers, consider their advantage as a backup source of information and measure this against the added cost they impose on your network infrastructure. A simple rule is that for each secondary server you add, network usage (because of added zone replication traffic) increases, and so does the time required to synchronize the zone at all secondary servers.

Secondary servers are most heavily used for forward lookup zones. If you are using reverse lookup zones, you can assume that you do not need to add as many secondary servers for those zones. Typically, a secondary server for a reverse lookup zone is not used outside of the network and subnet that correspond to the reverse zone.

Note

  • For more information, see To add a secondary server for an existing zone.


Securing the DNS Server service

To secure the DNS servers in your network, use the following guidelines:

  • Examine and configure the default DNS Server service settings that affect security. The following DNS Server service configuration options have security implications for both the standard and the Active Directory–integrated DNS Server service.
    • Default setting | Description
Interfaces | By default, a DNS Server service that is running on a multihomed computer is configured to listen for DNS queries using all of its IP addresses. Limit the IP addresses the DNS Server service listens on to the IP address used by its DNS clients as their preferred DNS server. For more information, see To restrict a DNS server to listen only on selected addresses.
Secure cache against pollution | By default, the DNS Server service is secured from cache pollution, which results when DNS query responses contain nonauthoritative or malicious data. The Secure cache against pollution option prevents an attacker from successfully polluting the cache of a DNS server with resource records that were not requested by the DNS server. Changing this default setting will reduce the integrity of the responses provided by DNS Server service. For more information, see To secure server cache against names pollution.
Disable recursion | By default, recursion is not disabled for the DNS Server service. This enables the DNS server to perform recursive queries on behalf of its DNS clients and DNS servers that have forwarded DNS client queries to it. Recursion can be used by attackers to deny the DNS Server service and therefore if a DNS server in your network is not intended to receive recursive queries, it should be disabled. For more information, see To disable recursion on the DNS server.
Root hints | If you have an internal DNS root in your DNS infrastructure, configure the root hints of internal DNS servers to only point to the DNS servers hosting your root domain and not the DNS servers hosting the Internet root domain. This will prevent your internal DNS servers from sending private information over the Internet when resolving names. For more information, see To update root hints on the DNS server and Updating root hints.

    For more information about default DNS Server service settings, see To restore server default preferences.

  • Manage the discretionary access control list (DACL) on DNS servers running on domain controllers. In addition to the default DNS Server service settings that affect security described above, DNS servers configured as domain controllers use a DACL. The DACL allows you to control the permissions for the Active Directory users and groups that control the DNS Server service.

    • The following table lists the default group or user names and permissions for the DNS Server service when it is running on a domain controller.

    Group or user names | Permissions
Administrators | Allow: Read, Write, Create All Child objects, Special Permissions
Authenticated Users | Allow: Read, Special Permissions
Creator Owner | Special Permissions
DnsAdmins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Domain Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Domain Controllers | Allow: Special Permissions
Pre-Windows 2000 Compatible Access | Allow: Special Permissions
System | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects

    For more information about assigning permissions on objects, see Best practices for assigning permissions on Active Directory objects, Best practices for permissions and user rights, and Understanding groups.

    When the DNS Server service is running on a domain controller, its DACL may be managed using the Active Directory object MicrosoftDNS. Configuring the DACL on the MicrosoftDNS Active Directory object has the same effect as configuring the DACL on the DNS server in the DNS console, which is the recommended method. Consequently, the security administrators of Active Directory objects and DNS servers should be in direct contact to ensure that the administrators do not reverse each other's security settings.

    For more information, see To assign, change, or remove permissions on Active Directory objects or attributes.

  • Always use an NTFS file system for DNS servers running a Windows Server 2003 operating system. The NTFS file system is a more powerful file system than FAT and FAT32 and provides a variety of features including Active Directory, which is needed for domains, user accounts, and other important security features.

    For more information about NTFS, see NTFS and NTFS compared to FAT and FAT32.

For more information, see Security information for DNS.


Using caching-only servers

Although all DNS servers cache queries that they have resolved, caching-only servers are DNS servers that only perform queries, cache the answers, and return the results. They are not authoritative for any domains and the information that they contain is limited to what has been cached while resolving queries.

In determining when to use this kind of server, note that when this server is initially started, it has no cached information. This information is obtained over time as client requests are serviced. However, if you are dealing with a slow-speed WAN link between sites, this option might be ideal because, once the cache is built, traffic decreases. In addition, the caching-only server does not perform zone transfers, which can also be network intensive in WAN environments.

Note

  • For more information, see To install a caching-only DNS server.


Modifying server defaults

The DNS console provides the ability to reconfigure some types of DNS server defaults for instances when defaults are not appropriate for use with a specific DNS server. Some configurable nondefault settings include:

  • Selecting an alternate server configuration method to be used when initiating service.
  • Disabling the use of recursion.

Methods for initiating service

The following methods are available to determine how the DNS Server service initializes and provides service when started.

Method | Description
From registry | Initializes the DNS Server service by reading parameters stored in the registry.
From file Initializes the DNS Server service using an optional boot file, as used by Berkeley Internet Name Domain (BIND) servers.

To use this file, supply a copy of a boot file from another DNS server running a DNS server that is based on the BIND implementation. On BIND-based DNS servers, this file is typically called the Named.boot file. The format of this file must be the older BIND 4 format, not the more recent BIND 8 boot file format.

If used, settings and directives in this file are used instead of comparable settings stored in the registry on the DNS server computer. For any parameters not configurable using boot file directives, registry defaults (or stored reconfigured server settings) are applied by the DNS Server service.

From Active Directory and registry | Initializes the DNS Server service by reading parameters stored in the Active Directory database and the server registry. This is the default boot option.

Notes

  • For more information on how to change the method used to initiate the DNS Server service, see To change the boot method used by the DNS server.

  • For more information on Active Directory integration with the DNS Server service, see Active Directory integration.

Disabling recursion

By default, recursion is enabled for the DNS Server service, and clients typically request that the server use recursion to resolve a name when sending a query. If recursion is disabled, the DNS Server service always uses referral, regardless of the client request.

In general, DNS servers can answer queries for names outside of their authoritative zones in two ways:

  • Servers can send referral answers, which are an immediate response to the requesting client with a list of resource records for other DNS servers it knows about that appear to be closer or more likely to be of help in resolving the queried name.
  • Servers can use recursion to query other servers on behalf of the requesting client, attempting to fully resolve the name. Recursive lookups continue until the server receives an authoritative answer for the queried name. The server then forwards this answer in response to the original query from the requesting client.

In most cases, disabling recursion on a DNS server happens when DNS clients are to be limited to resolving names authoritatively managed on a specific server. For example, this is the case when a DNS server has only DNS names data for an internal network or when the DNS server is incapable of resolving external DNS names (such as Internet DNS names) and clients are expected to retry another DNS server to resolve these names.

Notes

  • For more information on how to enable or disable the use of recursion with the DNS Server service, see To disable recursion on the DNS server.
  • If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.


Managing the aging and scavenging of server data

Aging and scavenging of stale resource records are features of DNS available when deploying your server with primary zones.

Where aging and scavenging are available for use, you can use the DNS console to perform the following related tasks for your DNS servers and any directory-integrated zones that they load:

  1. Enable or disable the use of scavenging at a DNS server.
  2. Enable or disable the use of scavenging for selected zones at the DNS server.
  3. Modify the no-refresh interval, either as a server default or by specifying an overriding value at selected zones.
  4. Modify the refresh interval, either as a server default or by specifying an overriding value at selected zones.
  5. Specify whether periodic scavenging occurs automatically at the DNS server for any of its eligible zones, and how often these operations are repeated.
  6. Manually initiate a single scavenging operation for all eligible zones at the DNS server.
  7. View other related properties, such as the time stamp for individual resource records or the start scavenging time for a specified zone.

Enabling scavenging of stale resource records

By default, aging and scavenging features are disabled on all DNS servers and any of their zones. Before using these features, you should configure these settings for the applicable server and its directory-integrated zones:

  • Server aging/scavenging properties for determining the use of these features on a server-wide basis.

    First, you need to enable aging and scavenging of stale resource records for use at the server. These settings are used to determine the affect of zone-level properties for any directory-integrated zones loaded at the server.

    For more information, see To set aging/scavenging properties for the DNS server.

  • Zone aging/scavenging properties for determining the use of these features on a per-zone basis.

    When zone-specific properties are set for a selected zone, these settings apply only to the applicable zone and its resource records. Unless these zone-level properties are otherwise configured, they inherit their defaults from comparable settings maintained in server aging/scavenging properties.

    For more information, see To set aging/scavenging properties for a selected zone.

Modifying no-refresh intervals

When the no-refresh interval is in effect for a specific resource record, attempts to dynamically refresh its time stamp are suppressed by the DNS server. This aspect of the aging/scavenging mechanism prevents unnecessary refreshes from being processed by the server for aged resource records. These early refresh attempts, if not handled in this way, might otherwise increase Active Directory replication traffic related to processing DNS zone changes.

To ensure that records do not refresh prematurely, keep the No-refresh interval comparable in length to the current refresh interval for each resource record. For example, if you increase the Refresh interval to a higher value you can similarly increase the no-refresh interval.

In most instances, the default interval of 7 days is sufficient and does not need to be changed.

Modifying refresh intervals

When the refresh interval is in effect for a resource record, attempts to dynamically refresh its time stamp are accepted and processed by the DNS server. When setting this interval, it is important that the length of time used be greater than the maximum possible refresh period for any resource records contained within the zone. This period is equal to the maximum amount of time that it might take the record to be refreshed under normal network conditions, based on the specific source generating the record refresh.

For example, the following table shows default refresh periods for various services known to dynamically register and refresh records in DNS:

Service | Default refresh period
Net logon | 24 hours
Clustering | 24 hours
DHCP client 24 hours

Note

  • The DHCP Client service sends dynamic updates for the DNS records. This includes both computers that obtain a leased IP address using DHCP and those that are configured statically for TCP/IP.
DHCP server 4 days (half of the lease interval, which is 8 days by default)

Note

  • Refresh attempts are only made by the DHCP servers configured to perform DNS dynamic updates on behalf of their clients (for example Windows 2000 Server DHCP server and Windows Server 2003 DHCP server). The period is based on the frequency in which DHCP clients renew their IP address leases with the server. Typically, this occurs when 50% of the scope lease time has elapsed. If the DNS default scope lease duration of 8 days is used, then the maximum refresh period for records updated by DHCP servers on behalf of clients is 4 days.

By default, the refresh interval is 7 days. In most instances, this value is sufficient and does not need to be changed, unless any resource records in the zone are refreshed less often than every 7 days.

Automated and manually-initiated scavenging

Although scavenging start time and other factors determine when zones and records are actually eligible for scavenging, you have the option to perform scavenging using either of two methods to initiate it:

  • Automatic scavenging specifies that aging and scavenging of stale records is to be performed automatically by the server for any eligible zones at a recurring interval specified as the scavenging period. When using automatic scavenging, the default scavenging period is 1 day and the minimum allowed value you can use is 1 hour.

    For more information, see To enable automatic scavenging of stale resource records.

  • Manual scavenging specifies that aging and scavenging of stale records is to be performed as a non-recurring operation for any eligible zones at the server.

    For more information, see To start immediate scavenging of stale resource records.

Modifying time stamp values

For resource records that are not dynamically added to DNS zone data, a record time stamp value of zero is applied, preventing these records from aging or removal during scavenging.

You can, however, manually reset record properties to enable any statically entered records to qualify for the aging/scavenging process. If you do this, the record will be deleted based upon the modified time stamp value, at which point, you might need to recreate a record if it is still needed.

For more information, see To reset scavenging and aging properties for a specified resource record.

Caution

  • Enabling aging and scavenging for use with standard primary zones modifies the format of zone files. This change does not affect zone replication to secondary servers, but the modified file cannot be loaded by other versions of DNS servers.
  • Before using information in this topic, be sure that you have reviewed the aging/scavenging process and use of its configurable properties and features. For more information, see Understanding aging and scavenging.

Note

  • For information on using Active Directory and DNS, see Active Directory integration.


Using forwarders

To use forwarders to manage the DNS traffic between your network and the Internet, configure the firewall used by your network to allow only one DNS server to communicate with the Internet. When you have configured the other DNS servers in your network to forward queries they cannot resolve locally to that DNS server it will act as your forwarder. For more information about forwarders, see Understanding forwarders.

Forwarding sequence

The order of the IP addresses listed as forwarders on a DNS server determines the sequence in which the IP addresses are used. After the DNS server forwards the query to the forwarder with the first IP address, it waits a short period for an answer from that forwarder (according to the DNS server's time out setting) before resuming the forwarding operation with the next IP address. It continues this process until it receives an affirmative answer from a forwarder.

For example, in the following figure the DNS servers with the first and second forwarder IP addresses do not respond to the DNS server. The DNS server with the third forwarder IP address responds and the query is forwarded to that DNS server.

DNS server forwards query to the DNS server with the first responsive IP address

Unlike conventional resolution, where a roundtrip time (RTT) is associated with each server, the IP addresses in the forwarders list are not ordered according to roundtrip time and must be reordered manually to change preference.

Conditional forwarders

Conditional forwarders are DNS servers used to forward queries according to domain names. Rather than having a DNS server forward all queries it cannot resolve locally to a forwarder, DNS servers can be configured to forward queries to different forwarders according to the specific domain names contained in the queries. Forwarding according to domain names improves conventional forwarding by adding a name-based condition to the forwarding process.

The conditional forwarder setting for a DNS server consists of the following:

  • The domain names for which the DNS server will forward queries.
  • One or more DNS server IP addresses for each domain name specified.

When a DNS client or server performs a query operation against a DNS server, the DNS server looks to see if the query can be resolved using its own zone data or the data stored in its cache. If the DNS server is configured to forward for the domain name designated in the query, then the query is forwarded to the IP address of a forwarder associated with the domain name. For example, in the following figure, each of the queries for the domain names is forwarded to a DNS server associated with the domain name.

Forwarding domain name queries to their associated DNS servers

If the DNS server has no forwarder listed for the name designated in the query, it attempts to resolve the query using standard recursion. For more information, see To configure a DNS server to use forwarders and How DNS query works.

Conditional forwarders allow you to improve name resolution between internal (private) DNS namespaces that are not part of the DNS namespace of the Internet, such as results from a company merger. By configuring the DNS servers in one internal namespace to forward all queries to the authoritative DNS servers in a second internal namespace, conditional forwarders enable name resolution between the two namespaces without performing recursion on the DNS namespace of the Internet. This enhancement to name resolution also avoids having your DNS servers perform recursion to your internal root for different namespaces within your network.

Important

  • A DNS server cannot forward queries for the domain names in the zones it hosts. For example, the authoritative DNS server for the zone widgets.example.com cannot forward queries according to the domain name widgets.example.com. The DNS server authoritative for widgets.example.com can forward queries for DNS names that end with hr.widgets.example.com, if hr.widgets.example.com is delegated to another DNS server.

Conditional forwarder domain name length

When a DNS server configured with a conditional forwarder receives a query for a domain name, it will compare that domain name with its list of domain name conditions and use the longest domain name condition that corresponds to the domain name in the query. For example, in the figure below, the DNS server performs the following conditional forwarding logic to determine how a query for a domain name will be forwarded:

  1. The DNS server receives a query for toys.widgets.example.com.
  2. It compares that domain name with both example.com and widgets.example.com.
  3. The DNS server determines that widgets.example.com is the domain name that more closely matches the domain name query.
  4. The DNS server forwards the query to the DNS server with the IP address 172.31.255.255, which is associated with widgets.example.com.
DNS server forwarding query according to domain name condition that comes closest to matching the name contained in the query

Forward-only servers

When a DNS server configured to use forwarders cannot resolve a query locally, or using its forwarders, the server attempts to resolve the query using standard recursion. A DNS server can also be configured to not perform recursion after forwarders fail. In this configuration, the server does not attempt any further recursive queries to resolve the name. Instead, if it does not get a successful query response from any of the servers configured as forwarders, then it fails the query. A DNS server configured in this manner is called a forward-only DNS server. If all forwarders for a name in the query do not respond to a forward-only DNS server, that DNS server will not attempt recursion.

A forward-only DNS server is different from a nonrecursive DNS server because it builds up a cache relating to the domain name and will use this cache to attempt to resolve the domain name. A nonrecursive DNS server will not build up a cache relating to the domain, nor will it perform recursion. In both configurations, the DNS servers will attempt to resolve the query using their authoritative data before using their forwarders.

Note

  • You can disable recursion for the entire DNS server or on a per domain name basis. If you disable recursion on the entire DNS server, you will not be able to use forwarders on that DNS server.

For more information, see Directing queries through forwarders and To disable recursion on the DNS server.


Directing queries through forwarders

A DNS server that acts as a forwarder may serve other purposes in the DNS environment. For example, it could be a primary or secondary server, or it could be a caching-only server. Consider the activities of all DNS servers in your network when deploying forwarders to ensure that forwarding complements the other DNS server activities and benefits name resolution. For general information about forwarders, see Understanding forwarders.

Forwarders and delegation

A DNS server configured with a forwarder and hosting a parent zone will use its delegation information before forwarding queries. If no delegation record exists for the DNS name in the query, then the DNS server will use its forwarders to resolve the query.

Forwarders and root servers

A common error when configuring forwarding is to attempt to configure forwarding on root servers for a private DNS namespace. Root servers are authoritative for the root zone of your organization's DNS namespace. The goal of attempting to configure forwarding on root servers for a private DNS namespace is to forward all offsite queries to Internet DNS servers. Root servers cannot be configured with standard forwarding. If an root server is queried about any domain name, then it will refer to a DNS server that can answer the question (from its local zones, cache or root hints), or it will respond with a failure (NXDOMAIN), but it cannot be configured to forward to specific servers.

Note

  • A root server can be configured with a conditional forwarder. Conditional forwarding can be used to forward queries between root servers in separate DNS namespaces.

Forwarder configuration tips

Consider the following tips for efficient forwarder configuration and use:

  • Keep forwarder configuration uncomplicated. For every DNS server configured with a forwarder, queries can be sent to a number of different places. Each forwarder and each conditional forwarder must be administered for the benefit of DNS client queries, and this process can be time consuming. Use forwarders strategically, where they are needed the most, such as resolving offsite queries or sharing information between namespaces.
  • Avoid chaining your forwarders. If you have configured a DNS server named server-1 to forward queries for widgets.example.com to DNS server server-2, do not configure server-2 to forward queries for widgets.example.com to DNS server server-3. This is an inefficient resolution process and could result in errors if server-3 is accidentally configured to forward queries for widgets.microsoft.com to server-1, in which case you would have a chain.
  • Do not concentrate too great of a load on forwarders. The recursive queries that forwarders send to the Internet can require a significant amount of time to answer due to the nature of the Internet. With a large number of internal DNS servers using these forwarders for Internet queries, they can experience a substantial concentration of network traffic. If network load will be an issue, use more than one forwarder and distribute the load between them.
  • Do not create inefficient resolution using forwarders. The DNS server will attempt to forward domain names according to the order in which they are configured in the DNS console. A DNS server in Seattle may be incorrectly configured to forward a query to a server in London instead of another server in Seattle because the server in London is higher in the forwarders list. This will decrease the efficiency of name resolution on the network. Evaluate your network's forwarding configuration periodically to see if there are similar configurations.

For more information, see To configure a DNS server to use forwarders.


Updating root hints

Root hints are used to prepare servers authoritative for non-root zones so that they can learn and discover authoritative servers that manage domains located at a higher level or in other subtrees of the DNS domain namespace. These hints are essential for servers authoritative at lower levels of the namespace when locating and finding servers under these conditions.

For example, suppose a DNS server (Server A) has a zone called sub.example.microsoft.com. In the process of answering a query for a higher-level domain, such as the example.microsoft.com domain, Server A needs some assistance to locate an authoritative server (such as Server B) for this domain.

In order for Server A to find Server B, or any other servers that are authoritative for the microsoft.com domain, it needs to be able to query the root servers for the DNS namespace. The root servers can then refer Server A to the authoritative servers for the com domain. The servers for the com domain can, in turn, offer referral to Server B or other servers that are authoritative for the microsoft.com domain.

The root hints used by Server A must have helpful hints to the root servers for this process to locate Server B (or another authoritative server) as intended.

To configure and use root hints correctly, first determine how the following applies to your DNS servers:

  • Are you using DNS on the Internet or on a private network?
  • Is the server used as a root server?

By default, the DNS Server service implements root hints using a file, Cache.dns, stored in the systemroot\System32\Dns folder on the server computer. This file normally contains the NS and A resource records for the Internet root servers. If, however, you are using the DNS Server service on a private network, you can edit or replace this file with similar records that point to your own internal root DNS servers.

Another server configuration in which root hints are treated differently is one in which a DNS server is configured to be used by other DNS servers in an internal namespace as a forwarder for any DNS queries of names managed externally (the Internet, for example). Even though the DNS server used as a forwarder can be located internally on the same network as servers using it as a forwarder, it needs hints for the Internet root servers to work properly and resolve external names.

Notes

  • If you are operating internal root servers, do not use root hints. Instead, delete the Cache.dns file entirely for any of your root servers.
  • If a DNS server is configured to know about other DNS servers, such as through a list of DNS servers configured in its client TCP/IP properties for an installed network connection, the DNS Server service is capable of gathering its own root hints during new server configuration. You can use the Configure a DNS Server Wizard provided with the DNS console to accomplish this.


Configuring multihomed servers

For multihomed DNS servers, you can configure the DNS Server service to selectively enable and bind only to IP addresses that you specify using the DNS console. By default, the DNS Server service binds to all IP interfaces configured for the computer.

This can include:

  • Any additional IP addresses configured for a single network connection.
  • Individual IP addresses configured for each separate connection where more than one network connection is installed on the server computer.

For multihomed DNS servers, you can restrict DNS service for selected IP addresses. When this feature is used, the DNS Server service only listens for and answers DNS requests that are sent to the IP addresses specified on the Interface tab in Server properties.

When to specify interfaces

By default, the DNS Server service listens on all IP addresses and accepts all client requests sent to its default service port (UDP 53 or TCP 53). Some DNS resolvers (including original version Windows 95 clients) require that the source address of a DNS response be the same as the destination address that was used in the query. If these addresses differ, clients can reject the response. To accommodate these resolvers, you can specify the list of allowed interfaces for the DNS server. When a list is set, the DNS Server service binds sockets only to allowed IP addresses used on the computer.

In addition to providing support for clients that require explicit bindings to be used, specifying interfaces can be useful for other reasons:

  1. If, for administrative reasons, you do not want to use some IP addresses or interfaces on a multihomed server computer.
  2. If the server computer is configured to use a large number of IP addresses and you do not want the added expense of binding to all of them.

Additional considerations for multihoming DNS servers

When configuring additional IP addresses and enabling them for use with a DNS server, consider the following:

  • Additional system resources are consumed at the server computer.
  • Although DNS provides the means to configure multiple IP addresses for use with any of your installed network adapters, there is no performance benefit for doing so.
  • Even if the DNS server is handling multiple zones registered for Internet use, it is not necessary or required by the Internet registration process to have different IP addresses registered for each zone.

Given these considerations:

  • Recognize that when adding IP addresses for DNS server use, each additional address might only slightly increase server performance. In instances when a large overall number of IP addresses are enabled for use, server performance can be degraded noticeably.
  • In general, when adding network adapter hardware to the server computer, assign only a single primary IP address for each network connection.
  • Whenever possible, remove non-essential IP addresses from existing server TCP/IP configurations.

Note

  • For more information on how to specify interfaces with the DNS Server service, see To restrict a DNS server to listen only on selected addresses.


Server administration using Dnscmd

Dnscmd is provided as a command-line tool for managing DNS servers. This tool can be used to script batch files, to help automate the management and update of existing DNS server configurations, or to perform set up and configuration of DNS servers.

For information about installing this tool, see To install Windows Support Tools. For help in using the command, type dnscmd /? at a command prompt or use the Windows Support Tools help.


Managing clients

This section covers:

  • Configuring DNS client settings
  • Configuring multiple names
  • Updating DNS client information
  • Securing DNS clients


Configuring DNS client settings

DNS configuration involves the following tasks when configuring TCP/IP properties for each computer:

  • Setting a DNS computer or host name for each computer. For example, in the fully qualified domain name (FQDN) wkstn1.example.microsoft.com., the DNS computer name is the leftmost label client1.
  • Setting a primary DNS suffix for the computer, which is placed after the computer or host name to form the FQDN. Using the previous example, the primary DNS suffix would be example.microsoft.com.
  • Setting a list of DNS servers for clients to use when resolving DNS names, such as a preferred DNS server, and any alternate DNS servers to use if the preferred server is not available.
  • Setting the DNS suffix search list or search method to be used by the client when it performs DNS query searches for short, unqualified domain names.

These tasks are discussed in more detail in each of the following sections.

Setting computer names

When setting computer names for DNS, it is useful to think of the name as the leftmost portion of a fully qualified domain name (FQDN). For example, in wkstn1.example.microsoft.com., wkstn1 is the computer name.

You can configure all Windows DNS clients with a computer name based on any of the standard supported characters defined in Request for Comments (RFC) 1123, "Requirements for Internet Hosts — Application and Support." These characters include the use of:

  • Uppercase letters, A through Z
  • Lowercase letters, a through z
  • Numbers, 0 through 9
  • Hyphens (-)

If you are supporting both NetBIOS and DNS namespaces on your network, you can use a different computer name within each namespace. It is recommended that wherever possible, however, you try to use computer names that are 15 characters or less and that you follow the RFC 1123 naming requirements outlined above.

By default, the leftmost label in the FQDN for clients equals the NetBIOS computer name, unless this label is 16 or more characters, which is the maximum for NetBIOS names. When the computer name exceeds the maximum length for NetBIOS, the NetBIOS computer name is truncated based on the full label that is specified.

Before configuring computers with varying DNS and NetBIOS names, consider the following implications and their related issues for your deployment:

  • If WINS lookup is enabled for zones hosted by your DNS servers, you need to use the same name for both NetBIOS and DNS computer naming. Otherwise, the results of clients attempting to query and resolve the names of these computers will be inconsistent.

If you have an investment in using NetBIOS names to support legacy Microsoft networking technology, it is recommended that you revise NetBIOS computer names used on your network to prepare for migration to a standard DNS-only environment. This prepares your network well for long-term growth and interoperability with future naming requirements. For example, if you use the same computer name for both NetBIOS and DNS resolution, consider converting any special characters such as the underscore (_) in your current NetBIOS names that do not comply with DNS naming standards. While these characters are permitted in NetBIOS names, they are more often incompatible with traditional DNS host naming requirements and most existing DNS resolver client software.

Notes

  • Although the use of the underscore (_) in DNS host names or in host (A) resource records has been traditionally prohibited by DNS standards, the use of underscores in service-related names—such as those used for service locator (SRV) resource records—has been proposed to avoid naming collisions in the Internet DNS namespace. For more information, see DNS RFCs.
  • In addition to DNS standard naming conventions, Windows Server 2003 DNS supports the use of extended ASCII and Unicode characters. However, since most resolver software written for other platforms (such as UNIX) is based on the Internet DNS standards, this enhanced character support can be used only in private networks with computers running Windows 2000 or Windows Server 2003 DNS.
  • The initial setup of DNS and TCP/IP displays a warning to suggest a standard DNS name if a nonstandard DNS name is entered.
  • By default, computers and servers use DNS to resolve any name that is greater than 15 characters in length. If the name is less than or equal to 15 characters, then both NetBIOS and DNS name resolution can be attempted and used to resolve the name.

Setting domain names

The domain name is used with the client computer name to form the fully qualified domain name (FQDN), known also as the full computer name. In general, the DNS domain name is the remainder of the FQDN that is not used as the unique host name for the computer.

For example, the DNS domain name used for a client computer could be the following: If the FQDN, or Full computer name, is wkstn1.example.microsoft.com, the domain name is the example.microsoft.com portion of this name.

DNS domain names have two variations—a DNS name and a NetBIOS name. The full computer name (a fully qualified DNS name) is used during querying and location of named resources on your network. For earlier version clients, the NetBIOS name is used to locate various types of NetBIOS services that are shared on your network.

An example that shows the need for both NetBIOS and DNS names is the Net Logon service. In Windows Server 2003 DNS, the Net Logon service on a domain controller registers its service (SRV) resource records on a DNS server. For Windows NT Server 4.0 and earlier versions, domain controllers register a DomainName entry in WINS to perform the same registration and to advertise their availability for providing authentication service to the network.

When a client computer is started on the network, it uses the DNS resolver to query a DNS server for SRV records for its configured domain name. This query is used to locate domain controllers and provide logon authentication for accessing network resources. A client or a domain controller on the network optionally uses the NetBIOS resolver service to query WINS servers, attempting to locate DomainName [1C] entries to complete the logon process.

Your DNS domain names should follow the same standards and recommended practices that apply to DNS computer naming described in the previous section. In general, acceptable naming conventions for domain names include the use of letters A through Z, numerals 0 through 9, and the hyphen (-). The use of the period (.) in a domain name is always used to separate the discrete parts of a domain name, commonly known as labels. Each label corresponds to an additional level defined in the DNS namespace tree.

For most computers, the primary DNS suffix configured for the computer can be the same as its Active Directory domain name, although the two values can also be different.

Important

  • By default, the primary DNS suffix portion of a computer's FQDN must be the same as the name of the Active Directory domain where the computer is located. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces or the Lightweight Directory Access Protocol (LDAP).

    • For more information, see Programming interfaces and Directory access protocol.

Configuring a DNS servers list

For DNS clients to operate effectively, a prioritized list of DNS name servers must be configured for each computer to use when processing queries and resolving DNS names. In most cases, the client computer contacts and uses its preferred DNS server, which is the first DNS server on its locally configured list. Listed alternate DNS servers are contacted and used when the preferred server is not available. For this reason, it is important that the preferred DNS server be appropriate for continuous client use under normal conditions.

Notes

  • For computers running XOX, the DNS server list is used by clients only to resolve DNS names. When clients send dynamic updates, such as when they change their DNS domain name or a configured IP address, they might contact these servers or other DNS servers as needed to update their DNS resource records. For more information, see Dynamic update.
  • By default, the DNS client on XOX does not attempt dynamic update over a Remote Access Service (RAS) or virtual private network connection. To modify this configuration, you can modify the advanced TCP/IP settings of the particular network connection or modify the registry. For more information, see To configure TCP/IP to use DNS and Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone named with a single-label name is considered a TLD zone, for example, com, edu, blank, my-company. To configure the DNS client to allow the dynamic update of TLD zones, you can use the Update Top Level Domain Zones policy setting or modify the registry.
  • When DNS clients are configured dynamically using a DHCP server, it is possible to have a larger list of provided DNS servers. To provide an IP address list of DNS servers to your DHCP clients, enable option code 6 on the configured options types provided by your DHCP server. For Windows Server 2003 DHCP servers, you can configure a list of up to 25 DNS servers for each client with this option.
  • To effectively share the load when multiple DNS servers are provided in a DHCP options-specified list, you can configure a separate DHCP scope that rotates the listed order of DNS and WINS servers provided to clients. For more information, see Configuring scopes.

Configuring a DNS suffix search list

For DNS clients, you can configure a DNS domain suffix search list that extends or revises their DNS search capabilities. By adding additional suffixes to the list, you can search for short, unqualified computer names in more than one specified DNS domain. Then, if a DNS query fails, the DNS Client service can use this list to append other name suffix endings to your original name and repeat DNS queries to the DNS server for these alternate FQDNs.

For computers and servers, the following default DNS search behavior is predetermined and used when completing and resolving short, unqualified names.

When the suffix search list is empty or unspecified, the primary DNS suffix of the computer is appended to short unqualified names, and a DNS query is used to resolve the resultant FQDN. If this query fails, the computer can try additional queries for alternate FQDNs by appending any connection-specific DNS suffix configured for network connections.

If no connection-specific suffixes are configured or queries for these resultant connection-specific FQDNs fail, then the client can then begin to retry queries based on systematic reduction of the primary suffix (also known as devolution).

For example, if the primary suffix were "example.microsoft.com", the devolution process would be able to retry queries for the short name by searching for it in the "microsoft.com" and "com" domains.

When the suffix search list is not empty and has at least one DNS suffix specified, attempts to qualify and resolve short DNS names is limited to searching only those FQDNs made possible by the specified suffix list. If queries for any FQDNs formed as a result of appending and trying each suffix in the list, the query process fails producing a "name not found" result.

Notes

  • If the domain suffix list is used, clients continue to send additional alternate queries based on different DNS domain names when a query is not answered or resolved. Once a name is resolved using an entry in the suffix list, unused list entries are not tried. For this reason, it is most efficient to order the list with the most used domain suffixes first.
  • Domain name suffix searches are used only when a DNS name entry is not fully qualified. To fully qualify a DNS name, a trailing period (.) is entered at the end of the name.


Configuring multiple names

Computers running XOX and servers running Windows Server 2003 are given DNS names by default. Each computer can have its DNS names configured using one of two possible methods:

  • A primary DNS domain name, which applies as the default fully qualified DNS name for the computer and all of its configured network connections.
  • A connection-specific DNS domain name, which can be configured as an alternate DNS domain name that applies only for a single network adapter installed and configured on the computer.

Although most computers do not need to support or use more than one name in DNS, support for configuring multiple connection-specific DNS names is sometimes useful. For example, by using multiple names, a user could specify which network connection to use when connecting to a multihomed computer.

Example: Using connection-specific names

As shown in the following figure, a multihomed server computer named "host-a" can be named according to both its primary and connection-specific DNS domain names.

Example: a multihomed DNS computer configured with multiple names

In this example, the server computer host-a attaches to two separate subnets — Subnet 1 and Subnet 2 — which are also linked at redundant points using two routers for additional paths between each subnet. Given this configuration, host-a provides access as follows through its separately named local area network (LAN) connections:

  • The name "host-a.public.example.microsoft.com" provides access using LAN connection 1 over Subnet 1, a lower-speed (10 megabit) Ethernet LAN, for normal access to users who have typical file and print service needs.
  • The name "host-a.backup.example.microsoft.com" provides access using LAN connection 2 over Subnet 2, a higher-speed (100 megabit) Ethernet LAN, for reserved access by server applications and administrators who have special needs, such as troubleshooting server networking problems, performing network-based backup, or replicating zone data between servers.

In addition to the connection-specific DNS names, the computer can also be accessible using either of the two LAN connections by specifying its primary DNS domain name, "host-a.example.microsoft.com".

When configured as shown, a computer can register resource records in DNS according to its three distinct names and sets of IP addresses, as shown in the following table:

DNS name | IP addresses | Description
host-a.example.microsoft.com | 10.1.1.11, 10.2.2.22 | Primary DNS name for computer. The computer registers A and PTR resource records for all configured IP addresses under this name in the "example.microsoft.com" zone.
host-a.public.example.microsoft.com | 10.1.1.11 | Connection-specific DNS name for LAN connection 1, which registers A and PTR resource records for IP address 10.1.1.11 in the "public.example.microsoft.com" zone.
host-a.backup.example.microsoft.com | 10.2.2.22 | Connection-specific DNS name for LAN connection 2, which registers A and PTR resource records for IP address 10.2.2.22 in the "backup.example.microsoft.com" zone.

Important

  • By default, the primary DNS suffix portion of a computer's fully qualified domain name (FQDN) must be the same as the name of the Active Directory domain where the computer is located. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces or the Lightweight Directory Access Protocol (LDAP).

    • For more information, see Programming interfaces and Directory access protocol.

Notes

  • DNS names can be set using remote administration and other remote configuration services, such as DHCP. For a DNS server running Windows Server 2003, the primary DNS domain name can be set using either remote administration or the unattended setup option.
  • For connection-specific naming, you can use TCP/IP configuration methods. You can manually configure the DNS domain name for each connection that appears in the Network Connections folder or use a DHCP option type (option code 15). For more information, see Advanced configuration.
  • For more information about DHCP options, see "DHCP Options" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Updating DNS client information

Updating DNS client information on a computer is sometimes necessary, for example, when a computer is added or removed from an Active Directory domain. In most cases, clients perform dynamic updates for the following changes when entering or leaving a domain:

  • When a computer is joined to a domain, it adds its A and PTR resource records to DNS.
  • When a computer is removed from a domain, it deletes its A and PTR resource records from DNS.

If you have enabled dynamic update for zones, these changes occur automatically. For more information, see Dynamic update.


Securing DNS clients

The following DNS client considerations have security implications for DNS clients in a DNS infrastructure:

  • Whenever possible, specify static IP addresses for the preferred and alternate DNS servers used by a DNS client. If a DNS client is configured to obtain its DNS server addresses automatically, it will obtain them from a DHCP server. While this method of obtaining DNS server addresses is secure, it is only as secure as the DHCP server. By configuring DNS clients with static IP addresses for the preferred and alternate DNS servers, you eliminate one possible avenue of attack.

    • For more information, see To configure TCP/IP to use DNS; To enable DNS for DHCP-enabled clients.

  • Control which DNS clients have access to the DNS server. If a DNS server is configured to listen only on specific IP addresses, then only DNS clients configured to use these IP addresses as preferred and alternate DNS servers will contact the DNS server.

    • For more information, see To restrict a DNS server to listen only on selected addresses.

For more information, see Security information for DNS.


Managing zones

This section covers:

  • Managing general properties
  • Managing authority records
  • Managing resource records
  • Delegating zones
  • Configuring notify lists
  • Securing DNS zones
  • Securing DNS resource records
  • Using stub zones
  • Active Directory–integrated stub zones
  • Contrasting stub zones and conditional forwarders
  • Checking names and zone data
  • Using WINS lookup
  • Managing reverse lookup zones


Managing general properties

When you add a zone using the DNS console, you can manage these general properties for it:

  • Pause or start the zone to interrupt or restore service for it.
  • Change or convert the type for the zone.
  • Disable or enable dynamic updates for the zone.

For Active Directory–integrated zones, you can enable the use of secure dynamic updates. This enables you to restrict updates to only a specific set of authorized users or systems. When a secure update policy is enabled for the zone, only users, systems, or groups authorized through Active Directory and included in the access control list (ACL) for each directory-integrated zone, are permitted to update the zone or specific resource records used in it.

In addition to these general zone properties, you can configure or manage the following zone properties using the DNS console:

  • Start of authority (SOA) properties These include properties supported by the SOA resource record, which is used to initialize the zone and indicate zone authority for a DNS domain name (and any of its subdomains not delegated away to other servers) to others in the DNS namespace. This record affects how often the zone must be renewed and transferred by other servers that load the zone and how long clients can cache resource records (RRs) when returned in answered queries for names in the zone. For more information on this record and configuring it, see Managing authority records.
  • Name server (NS) properties These include all fields supported by the NS resource record (RR) for the zone. The NS RR is used for designating the names of DNS servers authoritative for the zone to others. For more information on this record and configuring it, see Managing authority records.
  • Zone Transfer properties With this feature, you can configure how the zone permits transfers to be performed.

    You can choose to deny all requests to the server for transfer of this zone, to allow them only for other DNS servers configured on the Name Servers tab, or to transfer the zone only to DNS servers that you specify by IP address in a configured list.

    Using Notify located here, you can also enable and configure DNS notification for secondary servers of the zone. When notification is used, other servers (either those configured on the Name Servers tab or on a list that you specify) are notified of zone changes. These servers can then pull changes by initiating a zone transfer to update the zone.

    For more information, see Configuring notify lists.

    • Note

    • By default, the DNS server will only allow a zone transfer to authoritative DNS servers listed in the name server (NS) resource records for the zone.
  • WINS lookup properties The Windows Internet Name Service (WINS) lookup feature can be used to provide an expanded DNS name resolution path for zones when a queried name is not found in the zone. If WINS lookup is enabled for the zone, a WINS server (or list of WINS servers) can be contacted to assist in resolving a host name in the WINS-managed NetBIOS namespace. This feature is supported only by Microsoft DNS servers. For more information, see Using WINS lookup.


Managing authority records

Zones are based on a concept of server authority. When a DNS server is configured to load a zone, it uses two types of resource records to determine the authoritative properties of the zone:

  • First, the start of authority (SOA) resource record indicates the name of origin for the zone and contains the name of the server that is the primary source for information about the zone. It also indicates other basic properties of the zone.
  • Next, the name server (NS) resource record is used to notate which DNS servers are designated as authoritative for the zone. By listing a server in the NS RR, it becomes known to others as an authoritative server for the zone. This means that any server specified in the NS RR is to be considered an authoritative source by others, and is able to answer with certainty any queries made for names included in the zone.

The SOA and NS resource records occupy a special role in zone configuration. They are required records for any zone and are typically the first resource records listed in files. By default, the New Zone Wizard automatically creates these records when a new primary zone is added using the DNS console.

The SOA resource record

The start of authority (SOA) resource record is always first in any standard zone. It indicates the DNS server that either originally created it or is now the primary server for the zone. It is also used to store other properties such as version information and timings that affect zone renewal or expiration. These properties affect how often transfers of the zone are done between servers authoritative for the zone.

The SOA resource record contains the following information:

Field | Description
Primary server (owner) | The host name for the primary DNS server for the zone.
Responsible person | The e-mail address of the person responsible for administering the zone. A period (.) is used instead of an at sign (@) in this e-mail name.
Serial number | The revision number of the zone file. This number increases each time a resource record in the zone changes. It is important that this value increase each time the zone is changed, so that either partial zone changes or the fully revised zone can be replicated to other secondary servers during subsequent transfers.
Refresh interval | The time, in seconds, that a secondary DNS server waits before querying its source for the zone to attempt renewal of the zone. When the refresh interval expires, the secondary DNS server requests a copy of the current SOA record for the zone from its source, which answers this request. The secondary DNS server then compares the serial number of the source server's current SOA record (as indicated in the response) with the serial number in its own local SOA record. If they are different, the secondary DNS server requests a zone transfer from the primary DNS server. The default for this field is 900 seconds (15 minutes).
Retry interval | The time, in seconds, a secondary server waits before retrying a failed zone transfer. Normally, this time is less than the refresh interval. The default value is 600 seconds (10 minutes).
Expire interval | The time, in seconds, before a secondary server stops responding to queries after a lapsed refresh interval where the zone was not refreshed or updated. Expiration occurs because at this point in time, the secondary server must consider its local data unreliable. The default value is 86,400 seconds (24 hours).
Minimum (default) TTL | The default Time-To-Live (TTL) of the zone and the maximum interval for caching negative answers to name queries. The default value is 3,600 seconds (1 hour).

The following is an example of a default SOA resource record:

@   IN  SOA     nameserver.example.microsoft.com.  postmaster.example.microsoft.com. (
                               1            ; serial number
                               3600         ; refresh   [1h]
                               600          ; retry     [10m]
                               86400        ; expire    [1d]
                               3600 )       ; min TTL   [1h]

In the example SOA record shown above, the primary or originating server for the zone is shown as nameserver.example.microsoft.com. The e-mail address for the person to contact regarding questions about this zone is postmaster.example.microsoft.com.

Notes

  • Periods are used to represent e-mail addresses when writing and storing DNS domain names in a zone. In an e-mail application, the previous example address would instead likely appear as postmaster@example.microsoft.com.
  • The parentheses used in the SOA resource record as it appears in a zone file are used to enable wrapping of the record over multiple lines of text.
  • If an individual TTL value is assigned and applied to a specified resource record used in the zone, it overrides the minimum (default) TTL set in the SOA record.

The NS resource record

Name server (NS) resource records can be used to assign authority to specified servers for a DNS domain name in two ways:
  • By establishing a list of authoritative servers for the domain so that those servers can be made known to others that request information about this domain (zone).
  • By indicating authoritative DNS servers for any subdomains that are delegated away from the zone.

In the case of assigning servers with host names in the same zone, corresponding address (A) resource records are normally used in the zone to resolve the names of specified servers to their IP addresses. For servers that are specified using this RR as part of a zone delegation to a subdomain, the NS resource record usually contains out-of-zone names. For the out-of-zone names to be resolved, A resource records for the specified out-of-zone servers might be needed. When these out-of-zone NS and A records are needed to provide delegation, they are known as glue records.

Description: Used to map a DNS domain name as specified in owner to the name of hosts operating DNS servers specified in the name_server_domain_name field.
Syntax: owner ttl IN NS name_server_domain_name
Example:
example.microsoft.com.    IN NS  nameserver1.example.microsoft.com


Managing resource records

After you create a zone, additional resource records need to be added to it. The most common resource records (RRs) to be added are:

  • Host (A) For mapping a DNS domain name to an IP address used by a computer.
  • Alias (CNAME) For mapping an alias DNS domain name to another primary or canonical name.
  • Mail Exchanger (MX) For mapping a DNS domain name to the name of a computer that exchanges or forwards mail.
  • Pointer (PTR) For mapping a reverse DNS domain name based on the IP address of a computer that points to the forward DNS domain name of that computer.
  • Service location (SRV) For mapping a DNS domain name to a specified list of DNS host computers that offer a specific type of service, such as Active Directory domain controllers.
  • Other resource records as needed.

Host (A) resource records

Host (A) resource records are used in a zone to associate DNS domain names of computers (or hosts) to their IP addresses, and can be added to a zone in several ways:

  • You can manually create an A resource record for a static TCP/IP client computer using the DNS console.
  • Windows clients and servers use the DHCP Client service to dynamically register and update their own A resource records in DNS when an IP configuration change occurs.
  • DHCP-enabled client computers running earlier versions of Microsoft operating systems can have their A resource records registered and updated by proxy if they obtain their IP lease from a qualified DHCP server (only the Windows 2000 and Windows Server 2003 DHCP Server service currently supports this feature).

The host (A) resource record is not required for all computers, but is needed by computers that share resources on a network. Any computer that shares resources and needs to be identified by its DNS domain name, needs to use A resource records to provide DNS name resolution to the IP address for the computer.

Most A RRs that are required in a zone can include other workstations or servers that share resources, other DNS servers, mail servers, and Web servers. These resource records comprise the majority of resource records in a zone database.

For more information, see Resource records reference: A.

Alias (CNAME) resource records

Alias (CNAME) resource records are also sometimes called canonical names. These records allow you to use more than one name to point to a single host, making it easy to do such things as host both an FTP server and a Web server on the same computer. For example, the well-known server names (ftp, www) are registered using CNAME RRs that map to the DNS host name, such as "server-1", for the server computer that hosts these services.

CNAME RRs are recommended for use in the following scenarios:

  • When a host specified in an A RR in the same zone needs to be renamed.
  • When a generic name for a well-known server such as www needs to resolve to a group of individual computers (each with individual A RRs) that provide the same service. For example, a group of redundant Web servers.

When renaming a computer with an existing A RR in the zone, you can use a CNAME RR temporarily, to allow a grace period for users and programs to switch from specifying the old computer name to using the new one. To do this, you need the following:

  • For the new DNS domain name of the computer, a new A RR is added to the zone.
  • For the old DNS domain name, a CNAME RR is added that points to the new A RR.
  • The original A RR for the old DNS domain name (and its associated PTR RR if applicable) is removed from the zone.

When using a CNAME RR for aliasing or renaming a computer, set a temporary limit on how long the record is used in the zone before removing it from DNS. If you forget to delete the CNAME RR and later its associated A RR is deleted, the CNAME RR can waste server resources by trying to resolve queries for a name no longer used on the network.

The most common or popular use of a CNAME RR is to provide a permanent DNS aliased domain name for generic name resolution of a service-based name, such as www.example.microsoft.com to more than one computer or one IP address used in a Web server. For example, the following shows the basic syntax of how a CNAME RR is used.

alias_name IN CNAME primary_canonical_name

In this example, a computer named host-a.example.microsoft.com needs to function as both a Web server named "www.example.microsoft.com." and an FTP server named "ftp.example.microsoft.com." To achieve the intended use for naming this computer, you can add and use the following CNAME entries in the example.microsoft.com zone:

host-a    IN  A      10.0.0.20
ftp       IN  CNAME  host-a
www       IN  CNAME  host-a

If you later decide to move the FTP server to another computer, separate from the Web server on "host-a", simply change the CNAME RR in the zone for ftp.example.microsoft.com and add an additional A RR to the zone for the new computer hosting the FTP server.

Based on the earlier example, if the new computer were named "host-b.example.microsoft.com", the new and revised A and CNAME RRs would be as follows:

host-a    IN  A      10.0.0.20
host-b    IN  A      10.0.0.21
ftp       IN  CNAME  host-b
www       IN  CNAME  host-a

For more information, see Resource records reference: CNAME.

Mail exchanger (MX) resource records

The mail exchanger (MX) RR is used by e-mail applications to locate a mail server based on a DNS domain name used in the destination address for the e-mail recipient of a message. For example, a DNS query for the name "example.microsoft.com" could be used to find an MX RR, enabling an e-mail application to forward or exchange mail to a user with the e-mail address "user@microsoft.com."

The MX RR shows the DNS domain name for the computer or computers that process mail for a domain. If multiple MX RRs exist, the DNS Client service attempts to contact mail servers in the order of preference from lowest value (highest priority) to highest value (lowest priority). The following shows the basic syntax for use of an MX RR.

mail_domain_name IN MX preference mailserver_host

By using the MX RRs shown below in the example.microsoft.com zone, mail addressed to user@example.microsoft.com is delivered to user@mailserver0.example.microsoft.com first if possible. If this server is unavailable, the resolver client can then use user@mailserver1.example.microsoft.com instead.

@         IN  MX   1    mailserver0
@         IN  MX   2    mailserver1

Note that the use of the at sign (@) in the records indicates that the mailer DNS domain name is the same as the name of origin (example.microsoft.com) for the zone.

For more information, see Resource records reference: MX.

Pointer (PTR) resource records

Pointer (PTR) RRs are used to support the reverse lookup process, based on zones created and rooted in the in-addr.arpa domain. These records are used to locate a computer by its IP address and resolve this information to the DNS domain name for that computer.

PTR RRs can be added to a zone in several ways:

  • You can manually create a PTR RR for a static TCP/IP client computer using the DNS , either as a separate procedure or as part of the procedure for creating an A RR.
  • Computers use the DHCP Client service to dynamically register and update their PTR RR in DNS when an IP configuration change occurs.
  • All other DHCP-enabled client computers can have their PTR RRs registered and updated by the DHCP server if they obtain their IP lease from a qualified server. The Windows 2000 and Windows Server 2003 DHCP Server service provides this capability.

The pointer (PTR) resource record is used only in reverse lookup zones to support reverse lookup. For more information, see Resource records reference: PTR.

Service location (SRV) resource records

To locate Active Directory domain controllers, service location (SRV) RRs are required. Typically, you can avoid manual administration of the SRV RR when installing Active Directory.

By default, the Active Directory installation wizard attempts to locate a DNS server based on the list of preferred or alternate DNS servers, configured in any of its TCP/IP client properties, for any of its active network connections. If a DNS server that can accept dynamic update of the SRV RR (and other RRs related to registering Active Directory as a service in DNS) is contacted, the configuration process is complete.

If, during the installation, a DNS server that can accept updates for the DNS domain name used to name your Active Directory is not found, the wizard can install a DNS server locally and automatically configure it with a zone to support the Active Directory domain.

For example, if the Active Directory domain that you chose for your first domain in the forest was example.microsoft.com, a zone rooted at the DNS domain name of example.microsoft.com would be added and configured to use with the DNS server running on the new domain controller.

Whether or not you install the DNS Server service locally, a file (Netlogon.dns) is written and created during the Active Directory installation process that contains the SRV RRs and other RRs needed to support the use of Active Directory. This file is created in the systemroot\System32\Config folder.

If you are using a DNS server that fits one of the following descriptions, you should use the records in Netlogon.dns to manually configure the primary zone on that server to support Active Directory.

  1. The computer operating your DNS server is running on another platform, such as UNIX, and cannot accept or recognize dynamic updates.
  2. A DNS server at this computer that is not the DNS Server service provided with the Windows Server 2003 family is authoritative for the primary zone corresponding to the DNS domain name for your Active Directory domain.
  3. The DNS server supports the SRV RR, as defined in the Internet draft, "A DNS RR specifying the location of services (DNS SRV)", but does not support dynamic updates.

    For example, the DNS Server service provided with Windows NT Server 4.0, when updated to Service Pack 4 or later, fits this description.

In the future, the SRV RR might also be used to register and lookup other well-known TCP/IP services on your network if applications implement and support DNS name queries that specify this record type. For more information, see Resource records reference: SRV.

Other resource records

Other additional resource records are supported by Windows Server 2003 DNS and are used less frequently in most zones. These additional types of resource records can be added as needed using the DNS console. For more information about supported resource records, see Resource records reference.


Delegating zones

DNS provides the option of dividing up the namespace into one or more zones, which can then be stored, distributed, and replicated to other DNS servers. When deciding whether to divide your DNS namespace to make additional zones, consider the following reasons to use additional zones:

  • A need to delegate management of part of your DNS namespace to another location or department within your organization.
  • A need to divide one large zone into smaller zones for distributing traffic loads among multiple servers, improve DNS name resolution performance, or create a more fault-tolerant DNS environment.
  • A need to extend the namespace by adding numerous subdomains at once, such as to accommodate the opening of a new branch or site.

If, for any of these reasons, you could benefit from delegating zones, it might make sense to restructure your namespace by adding additional zones. When choosing how to structure zones, you should use a plan that reflects the structure of your organization.

When delegating zones within your namespace, be aware that for each new zone you create, you will need delegation records in other zones that point to the authoritative DNS servers for the new zone. This is necessary both to transfer authority and to provide correct referral to other DNS servers and clients of the new servers being made authoritative for the new zone.

When a standard primary zone is first created, it is stored as a text file containing all resource record information on a single DNS server. This server acts as the primary master for the zone. Zone information can be replicated to other DNS servers to improve fault tolerance and server performance.

When structuring your zones, there are several good reasons to use additional DNS servers for zone replication:

  1. Added DNS servers provide zone redundancy, enabling DNS names in the zone to be resolved for clients if a primary server for the zone stops responding.
  2. Added DNS servers can be placed so as to reduce DNS network traffic. For example, adding a DNS server to the opposing side of a low-speed WAN link can be useful in managing and reducing network traffic.
  3. Additional secondary servers can be used to reduce loads on a primary server for a zone.

Example: Delegating a subdomain to a new zone

As shown in the following figure, when a new zone for a subdomain (example.microsoft.com) is created, delegation from the parent zone (microsoft.com) is needed.

Example: How zone delegation works

In this example, an authoritative DNS server computer for the newly delegated example.microsoft.com subdomain is named based on a derivative subdomain included in the new zone (ns1.na.example.microsoft.com). To make this server known to others outside of the new delegated zone, two RRs are needed in the microsoft.com zone to complete delegation to the new zone.

These RRs include:

  • An NS RR to effect the delegation. This RR is used to advertise that the server named ns1.na.example.microsoft.com is an authoritative server for the delegated subdomain.
  • An A RR (also known as a glue record) is needed to resolve the name of the server specified in the NS RR to its IP address. The process of resolving the host name in this RR to the delegated DNS server in the NS RR is sometimes referred to as glue chasing.

Note

  • When zone delegations are correctly configured, normal zone referral behavior can sometimes be circumvented if you are using forwarders in your DNS server configuration. For more information, see Forwarders and delegation.


Configuring notify lists

Notify lists can be created and managed to provide a method for a master server for a zone (such as the primary server or another secondary server) to notify a list of secondary servers when the zone changes.

To create or manage a notify list, you can use the DNS console to add and remove servers by their IP addresses in the notify list for a zone. By default, the notify list is based on the authoritative servers for the zone as listed on the Name Servers tab.

Notes

  • For more information on how DNS notification works, see DNS Notify.
  • For more information on configuring and managing notify lists, see To create and manage a notify list for a zone.
  • You cannot configure a notify list for a stub zone.
  • By default, a DNS server running a Windows Server 2003 operating system will only allow a zone transfer to authoritative DNS servers listed in the name server (NS) resource records for the zone.


Securing DNS zones

The following DNS zone configuration options have security implications for both standard and Active Directory–integrated DNS zones:

  • Configure secure dynamic updates. By default, the Dynamic updates setting is not configured to allow dynamic updates. This is the most secure setting as it prevents an attacker from updating DNS zones, but this setting prevents you from taking advantage of the benefits to administration that dynamic update provides. To have computers securely update DNS data, store DNS zones in Active Directory and use the secure dynamic update feature. Secure dynamic update restricts DNS zone updates to only those computers that are authenticated and joined to the Active Directory domain where the DNS sever is located, and to the specific security settings defined in the ACLs for the DNS zone.

    • For more information, see To allow only secure dynamic updates.

  • Manage the discretionary access control list (DACL) on the DNS zones stored in Active Directory. The DACL allows you to control the permissions for the Active Directory users and groups that may control the DNS zones.

    • The following table lists the default group or user names and permissions for DNS zones stored in Active Directory.

    Group or user names | Permissions
Administrators | Allow: Read, Write, Create All Child objects, Special Permissions
Authenticated Users | Allow: Create All Child objects
Creator Owner | Special Permissions
DnsAdmins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Domain Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Domain Controllers | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Everyone | Allow: Read, Special Permissions
Pre-Windows 2000 Compatible Access | Allow: Special Permissions
System | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects

    For more information, see To modify security for a directory-integrated zone.

    The DNS Server service running on a domain controller that has zones stored in Active Directory stores its zone data in Active Directory using Active Directory objects and attributes. Configuring the DACL on the DNS Active Directory objects has the same effect as configuring the DACL on DNS zones in the DNS console. Consequently, the security administrators of Active Directory objects and DNS data should be in direct contact to ensure that the administrators do not reverse each other's security settings.

    The Active Directory objects and attributes used by DNS zone data stored in Active Directory are described in the following table.

    Object | Description
DnsZone | Container created when a zone is stored in Active Directory.
DnsNode | Leaf object used to map and associate a name in the zone to resource data.
DnsRecord | Multivalued attribute of a dnsNode object used to store the resource records associated with the named node object.
DnsProperty | Multivalued attribute of a dnsZone object used to store zone configuration information.

    For more information, see To assign, change, or remove permissions on Active Directory objects or attributes.

  • Restrict zone transfers. By default, the DNS Server service only allows zone information to be transferred to servers listed in the name server (NS) resource records of a zone. This is a secure configuration, but for increased security, this setting should be changed to the option to allow zone transfers to specified IP addresses. Changing this setting to allow zone transfers to any server may expose your DNS data to an attacker attempting to footprint your network.

    • For more information, see To modify DNS zone transfer settings.

  • Understand the compromise involved in zone delegation. When deciding whether to delegate DNS domain names to zones hosted on DNS servers that are administered separately, it is important to consider the security implications of giving multiple individuals the ability to administer the DNS data for your network. DNS zone delegation involves a compromise between the security benefits of having a single authoritative DNS server for all DNS data and the administrative benefits of distributing responsibility for your DNS namespace to separate administrators. This issue is very important when delegating the top-level domains of a private DNS namespace, as those domains contain very sensitive DNS data.

    • For more information, see Delegating zones.

DNS zone data recovery

If your DNS data has been corrupted you can restore your DNS zone file from the backup folder located in the systemroot/DNS/Backup folder. When a zone is first created, a copy of the zone is added to the backup folder. To recover the zone, copy the original zone file from the backup folder into the systemroot/DNS folder. When you use the New Zone Wizard to create the zone, specify the zone file in the systemroot/DNS folder as the zone file for the new zone. For more information, see To add a forward lookup zone.

Note

  • This operation only applies to standard zones that are not stored in Active Directory.

In the case of both standard and Active Directory–integrated zones, you should use the system backup feature to establish a standard data recovery procedure for your DNS infrastructure. For more information, see To create an Automated System Recovery set using Backup.

For more information, see Security information for DNS.


Securing DNS resource records

The following DNS resource record configuration options have security implications for resource records stored in both standard and Active Directory–integrated DNS zones:

  • Manage the discretionary access control list (DACL) on DNS resource records stored in Active Directory. The DACL allows you to control the permissions for the Active Directory users and groups that may control the DNS resource records. For more information, see To modify security for a resource record.

    • The following table lists the default group or user names and permissions for DNS resource records stored in Active Directory.

    Group or user names | Permissions
Administrators | Allow: Read, Write, Create All Child objects, Special Permissions
Authenticated Users | Allow: Create All Child objects
Creator Owner | Special Permissions
DnsAdmins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Domain Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Domain Controllers | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Everyone | Allow: Read, Special Permissions
Pre-Windows 2000 Compatible Access | Allow: Special Permissions
System | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects

For more information, see Security information for DNS.


Using stub zones

Use stub zones to:

  • Keep delegated zone information current. By updating a stub zone for one of its child zones regularly, the DNS server hosting both the parent zone and the stub zone will maintain a current list of authoritative DNS servers for the child zone.
  • Improve name resolution. Stub zones enable a DNS server to perform recursion using the stub zone's list of name servers without needing to query the Internet or internal root server for the DNS namespace.
  • Simplify DNS administration. By using stub zones throughout your DNS infrastructure, you can distribute a list of the authoritative DNS servers for a zone without using secondary zones. However, stub zones do not serve the same purpose as secondary zones and are not an alternative when considering redundancy and load sharing.

There are two lists of DNS servers involved in the loading and maintenance of a stub zone:

  • The list of master servers from which the DNS server loads and updates a stub zone. A master server may be a primary or secondary DNS server for the zone. In both cases, it will have a complete list of the DNS servers for the zone.
  • The list of the authoritative DNS servers for a zone. This list is contained in the stub zone using name server (NS) resource records.

When a DNS server loads a stub zone, such as widgets.example.com, it queries the master servers, which can be in different locations, for the necessary resource records of the authoritative servers for the zone widgets.example.com. The list of master servers may contain a single server or multiple servers and can be changed anytime. For more information, see To configure a stub zone to use local master servers.

Stub zone updates

Stub zone updates involve the following conditions:

  • When a DNS server loads a stub zone, it queries the zone's master server for the SOA resource record, NS resource records at the zone's root, and glue A resource records.
  • During updates to the stub zone, the master server is queried by the DNS server hosting the stub zone for the same resource record types requested during the loading of the stub zone.
  • The Refresh interval of the SOA resource record determines when the DNS server hosting the stub zone will attempt a zone transfer (update).
  • If an update fails, the Retry interval of the SOA resource record determines when the update is retried.
  • Once the Retry interval has expired without a successful update, the expiration time as specified in the Expires field of the SOA resource record determines when the DNS server stops using the stub zone data.

Use the DNS console in Microsoft Management Console (MMC) to perform the following stub zone update operations:

  • Reload. Reload the stub zone from the local storage of the DNS server hosting the stub zone.
  • Transfer from master. Have the DNS server hosting the stub zone determine if the serial number in the stub zone's SOA resource record has expired, and then perform a zone transfer from the stub zone's master server.
  • Reload from master. Perform a zone transfer from the stub zone's master server regardless of the serial number in the stub zone's SOA resource record.

For more information, see To reload or transfer a stub zone, To add a stub zone, and Understanding stub zones.


Active Directory-integrated stub zones

Microsoft Windows graphic

Active Directory–integrated stub zones

A stub zone can be stored in Active Directory on a DNS server configured as a domain controller. The following parameters are stored in the Active Directory–integrated stub zone:

  • Name of the stub zone, such as widgets.example.com.
  • Type of zone (stub zone).
  • List of master servers.

For more information, see Understanding stub zones and Active Directory integration.

Updating stub zones

When Active Directory–integrated stub zones are hosted in separate sites, you can update them using a local list of master servers in each site. For example, an Active Directory–integrated stub zone, widgets.example.com, was loaded in a site in Seattle and propagated to a site in Santiago, and master servers for the stub zone also exist in each of these sites. When the stub zone in Santiago is updated, the domain controller may contact both master servers for resource records for widgets.example.com, but for network traffic reasons, you might want the domain controller in Santiago to use only the master server in Santiago and not the master server in Seattle. To force the domain controller in Santiago to use only the master server in Santiago, you can specify that the stub zone in Santiago be updated using a local list of master servers.

For information about how to use a local list of master servers to update stub zones, see To configure a stub zone to use local master servers.


Contrasting stub zones and conditional forwarders

There can be some confusion about when to use conditional forwarders instead of stub zones because both DNS features allow a DNS server to respond to a query with a referral for, or by forwarding to, a different DNS server; however, these settings are used for very different purposes. These features have the following objectives:

  • A conditional forwarder setting configures the DNS server to forward a query it receives to a DNS server depending on the DNS name contained in the query.
  • A stub zone keeps the DNS server hosting a parent zone aware of all the DNS servers authoritative for a child zone.

Conditional forwarders

In situations where you want DNS clients in separate networks to resolve each others' names without having to query DNS servers on the Internet, such as in the case of a company merger, you should configure the DNS servers in each network to forward queries for names in the other network. DNS servers in one network will forward names for clients in the other network to a specific DNS server that will build up a large cache of information about the other network. When forwarding in this way, you create a direct point of contact between two networks' DNS servers, reducing the need for recursion.

Stub zones do not provide the same server–to–server benefit because a DNS server hosting a stub zone in one network will reply to queries for names in the other network with a list of all authoritative DNS servers for the zone with that name, instead of the specific DNS servers you have designated to handle this traffic. This configuration complicates any type of security settings that you want to establish between specific DNS servers running in each of the networks. For more information, see Understanding forwarders.

Stub zones

Stub zones are used when you want a DNS server hosting a parent zone to remain aware of the authoritative DNS servers for one of its child zones. If the stub zone for a child zone is hosted on the same DNS server as the parent zone, the DNS server hosting the stub zone will receive a list of all new authoritative DNS servers for the child zone when it requests an update from the stub zone's master server . This method of updating the DNS server hosting the parent zone maintains a current list of the authoritative DNS servers for the child zone as they are added and removed.

A conditional forwarder is not an efficient method of keeping a DNS server hosting a parent zone aware of the authoritative DNS servers for a child zone. If you used this method, whenever the authoritative DNS servers for the child zone changed, the conditional forwarder setting on the DNS server hosting the parent zone would have to be manually configured with the IP address for each new authoritative DNS server for the child zone. For more information, see Understanding stub zones.


Checking names and zone data

The following name-checking methods can be used with the DNS Server service and managed using the DNS console.

Method | Description
Strict RFC (ANSI) | Uses strict checking of names according to RFC 1123 Internet host naming specifications.
Non RFC (ANSI) | Permits names that are nonstandard and that do not follow RFC 1123 Internet host naming specifications.
Multibyte (UTF8) | Permits recognition of characters other than ASCII, including Unicode, which is normally encoded as more than one octet (8 bits) in length. With this option, multibyte characters can be transformed and represented using Unicode Transformation Format (UTF-8) support.
All names | Permits any naming conventions.

Notes

  • For more information on when to use nondefault settings for name checking with the DNS Server service, see Unicode character support.
  • For more information about RFCs, see DNS RFCs.

Checking for bad zone data

You can configure the DNS Server service to check for bad or unrecognized zone data when the service is started. To enable this option, see To prevent loading of a zone when bad data is found.

DNS wildcarding

The DNS Server service can use wildcards to associate multiple possible DNS name destinations with a single computer acting as a gateway for all names based on a wildcarded name. The most common use of wildcards in DNS records is with the mail exchanger (MX) resource record; for example, to configure DNS for an Internet mail gateway host routing mail between your private network and the Internet.

Basics of using DNS wildcards

When you are trying to determine where to use a wildcard in DNS, such as an MX resource record used to route and forward mail, note these guidelines:

  • The asterisk (*) is the character reserved to indicate the wildcarded name.
  • The asterisk is only used once as the leading (leftmost) character in a DNS name. For example, *.example.microsoft.com.
  • If used, an asterisk must always match at least one or more whole labels of a name that precede any non-wildcarded (exact) characters in the remaining part of the name. For example, the wildcard name *.example.microsoft.com may apply to one or more descendents of a domain, such as haifa.example.microsoft.com or seattle.us.example.microsoft.com, but it will not apply to the domain name itself, which is example.microsoft.com.
  • Wildcards are not used when a query for an exact name produces an exact match.
  • The contents of wildcarded resource records conform to normal DNS formats and rules for resource records.

Typically, wildcards are only used when the DNS name queried is an indeterminate name subordinate to a known name. In this case, the closest match to the wildcarded name is used. For example, if the following MX resource record is used in the example.microsoft.com zone:

*.example.microsoft.com. IN MX 10 mailserver1.example.microsoft.com.

This record would allow mail destined for the following possible DNS domain names to be routed to the mail routing host (mailserver1.example.microsoft.com.) specified in the MX resource record:

haifa.example.microsoft.com.
seattle.us.example.microsoft.com.
santiago.sa.example.microsoft.com.

When wildcarding is used, the asterisk (*) wildcard symbol must match at least one whole label beyond the specified part of the DNS name in which the wildcard is used.

For example, an e-mail message destined to user@example.microsoft.com could not use the previous example MX resource record to be forwarded to its destination. For the e-mail to be forwarded correctly, an additional explicit MX resource record needs to be added in the same zone, such as:

example.microsoft.com. IN MX 10 mailserver1.example.microsoft.com.

Loose RFC wildcarding

For Windows NT Server 4.0 (prior to Service Pack 4), the DNS Server service was not strictly compliant with the method for using wildcards in a DNS name lookup described in RFC 1034. It only stopped a wildcard lookup when it reached a node in the DNS domain namespace tree that had resource records of the type specified in a query.

For example, if in the example.microsoft.com. zone the following records were used:

      *.example.microsoft.com.             IN  MX  10   mailserver1.example.microsoft.com.
      example.microsoft.com.               IN  MX  10   mailserver2.example.microsoft.com.
      host-a.example.microsoft.com.        IN  A        10.0.0.1
      mailserver1.example.microsoft.com.   IN  A        10.0.0.2
      mailserver2.example.microsoft.com.   IN  A        10.0.0.3

and a DNS query was made by a computer, Host B, as follows:

Queried name: host-a.example.microsoft.com.
Queried type: MX

with loose wildcarding in effect, the following sequence occurs between the DNS Server service and Host B:

  1. Host B sends the example query to a DNS server configured to use loose RFC wildcarding, such as a DNS server running under Windows NT Server 4.0 prior to Service Pack 4.
  2. No MX resource records match the specified name (host-a.example.microsoft.com.).
  3. An MX resource record — the type specified in the query — is included in the zone and uses a wildcarded name that is the parent of the queried name (*.example.microsoft.com.).
  4. The DNS Server service checks the wildcarded MX resource record name (*.example.microsoft.com.) for its mapped host names, finds a matching A resource record for the specified name (mailserver1.example.microsoft.com.) and uses this information to answer Host B.
  5. The mail program on Host B can then send mail to mailserver1.example.microsoft.com. by using its IP address.

The loose RFC approach allows you to set up only two MX records and cover queries to the entire zone. However, the two MX resource records need to be added for both the zone root (the explicit name of the zone) and a wildcard node (*) directly below the zone root. However, if you have individual mail hosts that should receive their own mail directly, then add MX resource records for each of those hosts that refer directly to their own host name, as stated in their registered A resource record.

Strict RFC wildcarding

With the strict wildcarding approach as described in RFC 1034, a revised sequence of events occurs when reviewing the previous example. Based on the same specified zone and query information provided, the revised sequence of steps would be used between the DNS Server service and Host B:

  1. Host B sends the example query to a DNS server configured to use strict RFC wildcarding.
  2. No MX resource records match the specified name (host-a.example.microsoft.com.), but an A resource record of that name is found in the zone.

    Because the queried name was found, no wildcarding is done.

  3. The DNS Server service responds to the query with an authoritative negative response that includes no errors or resource records in the answer section of the response.
  4. The mail program on Host B then sends a new query for the same name, specifying that A resource records be used for the query type.
  5. The DNS Server service answers the A query with an authoritative positive response, which includes the A resource record in the answer section of the response.
  6. The mail program on Host B can then send mail to mailserver1.example.microsoft.com. by using its IP address.

The strict RFC approach to wildcarding is easier if your mail hosts are capable of receiving mail directly. The disadvantage to this approach is that you typically need to add more MX resource records to the zone. This can happen if you have mail hosts not capable of receiving mail directly, or if you need to advertise any mail hosts that are not mail servers.


Using WINS lookup

The DNS Server service provides the ability to use Windows Internet Name Service (WINS) servers to look up names not found in the DNS domain namespace by checking the NetBIOS namespace managed by WINS.

To use WINS lookup integration, two special resource record (RR) types—the WINS and WINS-R resource records—are enabled and added to a zone. When the WINS RR is used, DNS queries that fail to find a matched host (A) RR in the zone are forwarded to WINS servers configured in the WINS RR. For reverse lookup zones, the WINS-R RR can be enabled and used to provide a similar benefit for further resolving a reverse query not answerable in the reverse in-addr.arpa domain.

A good example of when to use WINS lookup is when you are using a mixed-mode client environment consisting of UNIX clients that use only DNS name resolution and earlier-version Microsoft clients that require NetBIOS naming. In these environments, WINS lookup provides a method for permitting UNIX DNS clients to locate your WINS clients by extending DNS host name resolution into the WINS-managed NetBIOS namespace.

The WINS lookup integration feature is only supported by Windows DNS servers. If you use a mixture of Windows and other DNS servers to host a zone, you should enable the Do not replicate this record check box option for any primary zones when using the WINS lookup record. This prevents the WINS lookup record from being included in zone transfers to other DNS servers that do not support or recognize this record. If you do not enable the WINS lookup record to be used only on the local server, it can cause data errors or failed zone transfers at servers running other DNS server implementations that replicate the zone.

The following sections discuss WINS lookup interoperability considerations and explain the following:

  • How the caching Time-To-Live (TTL) and lookup time-out values are configured for use with the WINS and WINS-R records.
  • The format of the WINS and WINS-R resource records as they are used in zone files created by the DNS Server service.

WINS lookup interoperability

Typically, WINS lookup provides the best and most predictable results if only Windows DNS servers are used, and is only available directly for use at Windows DNS servers. There are ways, however, that you use and benefit from WINS lookup as an interoperable solution when other DNS servers are deployed.

For example, consider adding a Windows DNS server that hosts a new WINS lookup-enabled zone. When creating and naming the zone, use a subdomain added to your existing DNS namespace that is used just for WINS-specific referrals added to your DNS domain namespace.

For instance, in example.microsoft.com, call the zone wins.example.microsoft.com when you create it. You can then use this new WINS referral zone as the root zone for any of your WINS-aware computers with names that are not found in your other traditional DNS zones.

In order to use the WINS referral zone, you need to specify its domain name (wins.example.microsoft.com) in a DNS suffix search list for your clients. The suffix list is configurable as part of the TCP/IP properties for a client connection and can be updated either manually, using DHCP, or using Group Policy. As long as the name of the WINS referral zone is included in the domain suffix list, any DNS names not resolved in traditional zones can be resolved using the WINS referral subdomain.

Under normal conditions, this should result in recursion from your other DNS servers to the Windows DNS servers that host the WINS-enabled zone. If the queried host names match NetBIOS computer names found in the WINS database, the names are resolved to the IP addresses mapped in WINS data there.

In our example the WINS-enabled zone is only used for WINS lookup, therefore no additional resource records need to be added to it. In general, WINS records could be added to any forward lookup zone.

By using a specific subdomain just for WINS lookup and specifying a static DNS suffix list to be used in resolving and searching for names, you can prevent unusual situations in which DNS queries for different FQDNs resolve to the same WINS client name and IP address. This might easily occur if you add and configure many zones at each level of your namespace and enable each of them to use WINS lookup integration.

For example, suppose you have two zones both configured to use WINS lookup. The zones are rooted and originate at the following DNS domain names:

example1.microsoft.com.
example2.microsoft.com.

With this configuration, a WINS client named HOST-A could be unintentionally resolved using either of the following FQDNs:

host-a.example1.microsoft.com.
host-a.example2.microsoft.com.

WINS resource record

Description: WINS forward lookup resource record. Used in a zone to provide further resolution of DNS queries for names not found in the zone by using a name query to WINS servers configured and listed with this record. If used, the WINS record only applies for the topmost level within a zone and not for subdomains used in the zone. The various fields that are used with the WINS RR include the following:
  • owner Indicates the owner domain for this record, should always be set to "@" to indicate that the current domain is the same as the zone origin.
  • class Indicates the class for this record, should always be set to "IN" as the Internet class is the only supported class for DNS servers running Windows Server 2003.
  • LOCAL When used, indicates that the WINS RR is to used only locally at the DNS server and is not to be included during zone replication with other DNS servers. This field corresponds to whether the Do not replicate this record check box was selected when configuring WINS lookup at the DNS console. If this check box was cleared, this field will not be included when the record is written to the zone.
  • lookup_timeout The lookup time-out value to be applied for this record. For more information, see Advanced parameters for WINS lookups.
  • cache_timeout The cache time-out value to be applied for this record. For more information, see Advanced parameters for WINS lookups.
  • wins_ip_addresses Used to specify one or more IP addresses of WINS servers. At least one IP address of a valid WINS server is required.
Syntax: owner class WINS [LOCAL] [L lookup_timeout] [Ccache_timeout] wins_ip_addresses
Example:
@ IN       WINS  10.0.0.1

@ IN       WINS LOCAL L1 C10 10.10.10.1 10.10.10.2 10.10.10.3

Note

  • In the provided example WINS records, the zone root is assumed to be the current origin.

WINS-R resource record

Description: WINS reverse lookup resource record. Used in a reverse lookup zone to provide further resolution for reverse queries not found in the zone by using a NetBIOS adapter node status query sent to the queried IP addresses. When this record is used, you need to specify the parent domain to be appended to a NetBIOS computer name when a successful reverse lookup occurs. Other fields used in the WINS-R record have similar description and purpose as described previously for their use in the WINS forward lookup record.
Syntax: owner class WINS [LOCAL] [L lookup_timeout] [Ccache_timeout] Domain_to_append_to_returned_NetBIOS_names
Example:
@ IN       WINS-R LOCAL L1 C10 example.microsoft.com.

@ IN       WINS-R wins.example.microsoft.com.

Note

  • In the provided example WINS-R records, the zone root is assumed to be the current origin.

Advanced parameters for WINS lookups

Two following advanced timing parameters are used with the WINS and WINS-R records:

  • The Cache timeout value, which indicates to a DNS server how long it should cache any of the information returned in a WINS lookup. By default, this value is set to 15 minutes.
  • The Lookup timeout value, which specifies how long to wait before timing out and expiring a WINS lookup performed by the DNS Server service. By default, this value is set to 2 seconds.

These parameters are configured using the Advanced button in the zone properties dialog box when you configure the zone. This button appears on either the WINS or WINS-R tab, depending on whether the zone you are configuring is being used for forward lookup or reverse lookup.

If you are using either the WINS or WINS-R resource record, be aware that the minimum Time-To-Live (TTL) set in the SOA record for the zone is not the default TTL used with these records. Instead, when either an IP address or a host name gets resolved with WINS lookup, the information is cached on the DNS server for the amount of time configured for the WINS cache time-out value. If this address is then ever forwarded to another DNS server, the WINS cache time-out value TTL is what is sent. If your WINS data rarely changes, you can increase the default TTL of 15 minutes.

Notes

  • If you have a zone configured for WINS lookup, then all DNS servers that are authoritative for that zone need to be capable of WINS lookup or you will have intermittent behavior.
  • Because you can select that the WINS and WINS-R RRs not be replicated to other DNS servers, you can selectively enable and configure WINS lookup at each of your secondary servers for zones where this feature is used. This is not a standard practice for other types of resource records which are only to be configured at the primary server for the zone.


Managing reverse lookup zones

When adding reverse lookup zones, you can simplify the process of adding pointer (PTR) resource records to these zones by:

  • Using the Update associated pointer (PTR) record option when manually adding host (A) resource records to forward lookup zones.
  • Deploying DHCP servers and enabling DHCP-DNS integration features to help manage and update reverse lookup zones for legacy clients.
  • Installing XOX as the standard operating system in your organization for deploying new client hardware.

    With XOX on your client computers, either the client or its Windows Server 2003 DHCP server can be enabled to perform pointer (PTR) resource record registration for the client when its IP address is obtained and configured.

Subnetted reverse lookup zones

Default subnet masks (which have either a value of 0 or 255 used in each of the four octets of the masked value) are assumed by the DNS when configuring a new reverse lookup zone. If necessary, you can use custom subnetting to adjust the subnet mask value to a nondefault length.

Subnetted reverse lookup zones are supported when using the Advanced view setting available through Microsoft Management Console (MMC) and the DNS . This allows you to add and configure a reverse lookup for an IP network address that uses nondefault subnet mask lengths, such as 255.255.248.0, which has a nondefault subnet value of 248 in the third octet.

For more information, see Microsoft Windows Deployment and Resource Kits.

Notes

  • Subnetted reverse lookup zones are further described in RFC 2317, "Classless IN-ADDR.ARPA delegation." For more information on RFCs or how to obtain them, see TCP/IP RFCs.
  • PTR resource records created automatically when adding an A resource record to a zone will be deleted automatically if the corresponding A resource record is deleted.


Monitoring and optimizing servers

This section covers:

  • Monitoring DNS server performance
  • Using server debug logging options
  • Verifying server configuration
  • Configuring round robin
  • Prioritizing local subnets
  • Tuning advanced server parameters
  • Using DNS Security Extensions (DNSSEC)
  • Using Extension Mechanisms for DNS (EDNS0)


Monitoring DNS server performance

Because DNS servers are of critical importance in most environments, monitoring their performance can help in the following ways:

  • By providing a useful benchmark for predicting, estimating, and optimizing DNS server performance.
  • In troubleshooting DNS servers where server performance has degraded either over time or during periods of peak activity.

As you begin your DNS server monitoring, you can review sample test results for DNS servers that were collected during product development and testing. You can use this information as a starting reference as you begin to monitor your DNS servers to measure and benchmark performance.

A set of DNS server performance counters are provided with System Monitor to measure and monitor various aspects of server activity.

Sample DNS server performance test results

The DNS development and testing team compiled some statistics as a profile of DNS server performance during preliminary testing. In testing, two different DNS server hardware configurations were used and overall DNS query and dynamic update activity was measured, along with processor utilization.

The results of each of these tests are listed in the table below.

Server configuration | Queries/sec | Dynamic updates/sec | Processor utilization
Intel P-III 733 MHz single-processor | 9500 | 1300 | 75%

During the collection of these measurements (over 4 days), the monitored DNS server was processing both queries and dynamic updates simultaneously. The numbers above reflect this.

For dynamic updates, standard primary type zones were used, not Active Directory–integrated zones. Where directory integration is used for zones, the rate at which dynamic updates can be processed decreases, since the DNS server must additionally write to and rely upon the Active Directory database.

In addition, if a zone is configured to accept only secure dynamic updates, the update rate can also decrease. Network performance might also be a factor in these cases since the directory database may require network activity to process updates.

For additional background information about the two server hardware configurations used during these tests, see the following section.

Important

  • These measurements are not intended to indicate maximum performance or server limitations for DNS servers running Windows Server 2003. The objective of the tests was to sample typical DNS server performance and obtain a working benchmark based on standard available hardware as a basis to begin server capacity planning.
  • Note that these numbers are approximate and can be influenced by the type of resource records entered in zones, the number of resource records with the same owner name, and the number of zones in use at a specific DNS server.

Background information on sample DNS server tests

The list of specific hardware that the Windows Server 2003 DNS development and test team used during the described testing included the following:

Hardware components | Sizing
Number of processors | One
Processor | Intel Pentium III 733 MHz
Amount of RAM | 256 MB (megabytes)
Hard disk drive space | 4 GB (gigabytes)

These measurements were based on the server computer running a DNS server, with no additional services in use. Where other hardware specifications or software configurations are made when deploying DNS servers, your performance results are likely to vary from those documented here.

For more information on determining how to perform DNS server capacity planning, see Server planning for DNS.

DNS server performance counters

DNS server performance counters can be used to measure and monitor various aspects of server activity, such as the following:

  • Overall DNS server performance statistics, such as the number of overall queries and responses processed by a DNS server.
  • User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) counters, for measuring DNS queries and responses that are processed respectively using either of these transport protocols.
  • Dynamic update and secure dynamic update counters, for measuring registration and update activity generated by dynamic clients.
  • Memory usage counters, for measuring system memory usage and memory allocation patterns created by operating the server computer as a DNS server running Windows Server 2003.
  • Recursive lookup counters, for measuring queries and responses when the DNS Server service uses recursion to look up and fully resolve DNS names on behalf of requesting clients.
  • WINS lookup counters, for measuring queries and responses made to WINS servers when the WINS lookup integration features of the DNS Server service are used.
  • Zone transfer counters, including specific counters for measuring: all zone transfer (AXFR), incremental zone transfer (IXFR), and DNS zone update notification activity.

Each of these DNS server performance counters is described in more detail in the following sections.

All zone transfer (AXFR) counters

Field | Description
AXFR Request Received | The total number of full zone transfer requests received by the DNS Server service when operating as a master server for a zone.
AXFR Request Sent | The total number of full zone transfer requests sent by the DNS Server service when operating as a secondary server for a zone.
AXFR Response Received | The total number of full zone transfer requests received by the DNS Server service when operating as a secondary server for a zone.
AXFR Success Received | The total number of full zone transfers received by the DNS Server service when operating as a secondary server for a zone.
AXFR Success Sent | The total number of full zone transfers successfully sent by the DNS Server service when operating as a master server for a zone.

DNS server memory counters

Field | Description
Caching Memory | The total amount of system memory in use by the DNS Server service for caching.
Database Node Memory | The total amount of system memory in use by the DNS Server service for database nodes.
Nbtstat Memory | The total amount of system memory in use by the DNS Server service for Nbtstat.
Record Flow Memory | The total amount of system memory in use by the DNS Server service for record flow.

Dynamic update counters

Field | Description
Dynamic Update NoOperation | The total number of No-operation/Empty dynamic update requests received by the DNS server.
Dynamic Update NoOperation/sec | The average number of No-operation/Empty dynamic update requests received by the DNS server in each second.
Dynamic Update Queued | The total number of dynamic updates queued by the DNS server.
Dynamic Update Received | The total number of dynamic update requests received by the DNS server.
Dynamic Update Received/sec | The average number of dynamic update requests received by the DNS server in each second.
Dynamic Update Rejected | The total number of dynamic updates rejected by the DNS server.
Dynamic Update TimeOuts | The total number of dynamic update time-outs of the DNS server.
Dynamic Update Written to Database | The total number of dynamic updates written to the database by the DNS server.
Dynamic Update Written to Database/sec | The average number of dynamic updates written to the database by the DNS server in each second.

Incremental zone transfer (IXFR) counters

Field | Description
IXFR Request Received | The total number of incremental zone transfer requests received by the master DNS server.
IXFR Request Sent | The total number of incremental zone transfer requests sent by the secondary DNS server.
IXFR Response Received | The total number of incremental zone transfer responses received by the secondary DNS server.
IXFR Success Received | The total number of successful incremental zone transfers received by the secondary DNS server.
IXFR Success Sent | The total number of successful incremental zone transfers of the master DNS server.
IXFR TCP Success Received | The total number of successful TCP incremental zone transfers received by the secondary DNS server.
IXFR UDP Success Received | The total number of successful UDP incremental zone transfers received by the secondary DNS server.

Notification counters

Field | Description
Notify Received | The total number of notifies received by the secondary DNS server.
Notify Sent | The total number of notifies sent by the master DNS server.

Recursion counters

Field | Description
Recursive Queries | The total number of recursive queries received by the DNS server.
Recursive Queries/sec | The average number of recursive queries received by the DNS server in each second.
Recursive Query Failure | The total number of recursive query failures.
Recursive Query Failure/sec | The average number of recursive query failures in each second.
Recursive TimeOuts | The total number of recursive query sending time-outs.
Recursive TimeOuts/sec | The average number of recursive query sending time-outs in each second.

Secure dynamic update counters

Field | Description
Secure Update Failure | The total number of secure updates failed on the DNS server.
Secure Update Received | The total number of secure update requests received by the DNS server.
Secure Update Received/sec | The average number of secure update requests received by the DNS server in each second.

TCP counters

Field | Description
TCP Message Memory | The total TCP message memory used by the DNS server.
TCP Query Received | The total number of TCP queries received by the DNS server.
TCP Query Received/sec | The average number of TCP queries received by the DNS server in each second.
TCP Response Sent | The total number of TCP responses sent by the DNS server.
TCP Response Sent/sec | The average number of TCP responses sent by the DNS server in each second.

Total (overall performance) counters

Field | Description
Total Query Received | The total number of queries received by the DNS server.
Total Query Received/sec | The average number of queries received by the DNS server in each second.
Total Response Sent | The total number of responses sent by the DNS server.
Total Response Sent/sec | The average number of responses sent by the DNS server in each second.

UDP counters

Field | Description
UDP Message Memory | The total UDP message memory used by the DNS server.
UDP Query Received | The total number of UDP queries received by the DNS server.
UDP Query Received/sec | The average number of UDP queries received by the DNS server in each second.
UDP Response Sent | The total number of UDP responses sent by the DNS server.
UDP Response Sent/sec | The average number of UDP responses sent by the DNS server in each second.

WINS lookup counters

Field | Description
WINS Lookup Received | The total number of WINS lookup requests received by the server.
WINS Lookup Received/sec | The average number of WINS lookup requests received by the server in each second.
WINS Response Sent | The total number of WINS lookup responses sent by the server.
WINS Response Sent/sec | The average number of WINS lookup responses sent by the server in each second.
WINS Reverse Lookup Received | The total number of WINS reverse lookup requests received by the server.
WINS Reverse Lookup Received/sec | The average number of WINS reverse lookup requests received by the server in each second.
WINS Reverse Response Sent | The total number of WINS Reverse lookup responses sent by the server.
WINS Reverse Response Sent/sec | The average number of WINS Reverse lookup responses sent by the server in each second.

Zone transfer counters

Field | Description
Zone Transfer Failure | The total number of failed zone transfers of the master DNS server.
Zone Transfer Request Received | The total number of zone transfer requests received by the master DNS server.
Zone Transfer SOA Request Sent | The total number of zone transfer SOA requests sent by the secondary DNS server.
Zone Transfer Success | The total number of successful zone transfers of the master DNS server.


Using server debug logging options

The following DNS debug logging options are available:

  • Direction of packets

    • Send Packets sent by the DNS server are logged in the DNS server log file.

    Receive Packets received by the DNS server are logged in the log file.

  • Content of packets

    • Standard queries Specifies that packets containing standard queries (per RFC 1034) are logged in the DNS server log file.

    Updates Specifies that packets containing dynamic updates (per RFC 2136) are logged in the DNS server log file.

    Notifies Specifies that packets containing notifications (per RFC 1996) are logged in the DNS server log file.

  • Transport protocol

    • UDP Specifies that packets sent and received over UDP are logged in the DNS server log file.

    TCP Specifies that packets sent and received over TCP are logged in the DNS server log file.

  • Type of packet

    • Request Specifies that request packets are logged in the DNS server log file (a request packet is characterized by a QR bit set to 0 in the DNS message header).

    Response Specifies that response packets are logged in the DNS server log file (a response packet is characterized by a QR bit set to 1 in the DNS message header).

  • Enable filtering based on IP address Provides additional filtering of packets logged in the DNS server log file. This option allows logging of packets sent from specific IP addresses to a DNS server, or from a DNS server to specific IP addresses.

  • File name Lets you specify the name and location of the DNS server log file.

    • For example:

    • dns.log specifies that the DNS server log file should be saved as dns.log in the systemroot\System32\Dns directory.
    • temp\dns.log specifies that the DNS server log file should be saved as dns.log in the systemroot\Temp directory

  • Log file maximum size limit Lets you set the maximum file size for the DNS server log file. When the specified maximum size of the DNS server log file is reached, the DNS server overwrites the oldest packet information with new information. Note: If left unspecified, the DNS server log file's size can take up a large amount of hard disk space.

By default, all debug logging options are disabled. When selectively enabled, the DNS Server service can perform additional trace-level logging of selected types of events or messages for general troubleshooting and debugging of the server.

Debug logging can be resource intensive, affecting overall server performance and consuming disk space. Therefore, it should only be used temporarily when more detailed information about server performance is needed.

Notes

  • Dns.log contains debug logging activity. By default, it is located in the windir\System32\Dns folder.
  • To enable and use file-based logging, see To select and enable debug logging options on the DNS server.
  • For more information about RFCs, see DNS RFCs.


Verifying server configuration

When using the DNS console, you can perform either manual or automated verification testing of your DNS servers to monitor their ability to process and resolve queries. This feature is accessed through the Monitoring tab in DNS server properties.

When using this feature, two types of test are available:

  • A simple query against this DNS server.

    This type of test specifies that the DNS server perform a simple or iterative query. This test is a localized query using the DNS resolver (client) on the server computer to query the local DNS server (also located on the same computer).

    For more information, see How iteration works.

  • A recursive query to other DNS servers.

    This type of test specifies that the DNS server perform a recursive query. This test is similar in its initial query processing to the previous test in that it uses the local DNS resolver (client) to query the local DNS server, also located on the same computer.

    In this test, however, the client asks the server to use recursion to resolve an NS-type query for the root of the DNS domain namespace, stated as a single dot ("."). This type of query should typically require additional recursive processing and can be helpful in verifying that server root hints or zone delegations have been properly set.

    For more information, see How DNS query works.

Once you have selected the tests to be used, you can either click the Test Now button to manually perform the tests immediately, or you can perform automatic testing at a specified time interval.

Automated tests are performed when the Perform automatic testing at the following interval check box is selected and a test interval is specified in Test interval.

Results of all selected tests, whether manually or automatically performed, are displayed in the Test results list box. Typically, this information includes:

  • The date and time when each query was made.
  • Additional status results of the specific test used, such as whether the simple or recursive query failed or succeeded.


Configuring round robin

Round robin is a local balancing mechanism used by DNS servers to share and distribute network resource loads. You can use it to rotate all resource record (RR) types contained in a query answer if multiple RRs are found.

By default, DNS uses round robin to rotate the order of RR data returned in query answers where multiple RRs of the same type exist for a queried DNS domain name. This feature provides a simple method for load balancing client use of Web servers and other frequently queried multihomed computers.

If round robin is disabled for a DNS server, the order of the response for these queries is based on a static ordering of RRs in the answer list as they are stored in the zone (either its zone file or Active Directory).

Example: Round-robin rotation

A forward lookup-type query (for all A RRs that match a DNS domain name) is made for a multihomed computer (multihomed.example.microsoft.com) that has three IP addresses. Separate A RRs are used to map the host's name to each of these IP addresses in the zone. In the stored example.microsoft.com zone, the RRs appear in this fixed order:

multihomed IN A 10.0.0.1
multihomed IN A 10.0.0.2
multihomed IN A 10.0.0.3

The first DNS client that queries the server to resolve this host's name receives the list in default order. When a second client sends a subsequent query to resolve this name, the list is rotated as follows:

multihomed IN A 10.0.0.2
multihomed IN A 10.0.0.3
multihomed IN A 10.0.0.1

Restricting round-robin rotation for selected RR types

By default, DNS will perform round-robin rotation for all RR types. You can specify that certain RR types are not to be round-robin rotated in the registry. There is a registry entry called DoNotRoundRobinTypes (REG_SZ) with a string value containing a list of RR types. By modifying this entry, you turn off round-robin rotation for specific RR types. For example, to prevent round-robin rotation for A, PTR, SRV, and NS record types, you would enter the following value for the registry entry:

a ptr srv ns

Restricting round-robin rotation for all RR types

The default setting for round-robin rotation is contained in the registry entry RoundRobin (REG_DWORD). By default, this entry's value is 1, rotating all RR types except those listed in the DoNotRoundRobinTypes registry entry. If the value of RoundRobin is set to 0, then no RR types will be round-robin rotated.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.

Notes

  • The string value for the DoNotRoundRobinTypes registry entry may contain types in numeric (as shown above) of mnemonic formats.

  • Both of the round robin registry entries must be created and stored in the following registry subkey:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

  • Local subnet priority supersedes the use of round-robin rotation for multihomed names. When enabled, round-robin continues to be a secondary method used to sort multiple RRs returned in a listed answer. For more information on local subnet priority, see Prioritizing local subnets.


Prioritizing local subnets

By default, the DNS Server service uses local subnet prioritizing as the method for giving preference to IP addresses on the same network when a client query resolves to a host name that is mapped to more than one IP address. This feature requires that the client application attempt to connect to the host using its closest (and typically fastest) IP address available for connection.

The DNS Server service uses local subnet priority as follows:

  1. The DNS Server service determines if local subnet prioritization is needed to order the query response.

    If more than one A resource record (RR) matches the queried host name, the DNS Server service can reorder the records by their subnet location. If the queried host name only matches a single A resource record, or if the IP network address of the client does not match an IP network address for any of the mapped addresses in an answer list of multiple RRs, no prioritizing is necessary.

  2. For each RR in the matched answer list, the DNS Server service determines which records (if any) match the subnet location of the requesting client.
  3. The DNS Server service reorders the answer list so that A RRs which match the local subnet of the requesting client are placed first in the answer list.
  4. Prioritized by subnet order, the answer list is returned to the requesting client.

Simple example: Local network prioritizing

A multihomed computer, multihomed.example.microsoft.com, has three A RRs for its three separate host IP addresses in the example.microsoft.com zone. A separate A RR is used for each of the host's addresses, which appear in this order in the zone:

multihomed IN A 192.168.1.27
multihomed IN A 10.0.0.14
multihomed IN A 172.16.20.4

If a DNS client resolver at IP address 10.4.3.2 queries the server for the IP addresses of host multihomed.example.microsoft.com, the DNS Server service notes that the originating IP network address (10.0.0.0) of the client matches the network (class A) portion of the 10.0.0.4 address in the answer list of RRs. The DNS Server service then reorders the addresses in the response as follows:

multihomed IN A 10.0.0.14
multihomed IN A 192.168.1.27
multihomed IN A 172.16.20.4

If the IP address of the requesting client has no local network match with any of the RRs in the answer list, then the list is not prioritized.

Complex example: Local subnet prioritizing

If you are working in a network that uses IP subnetting (nondefault subnet masks), there are only a few minor differences. If more than one address matches in the network portion, then the matching addresses are further ordered and the RR having the closest matching subnet address is placed first.

For example, a multihomed computer, multihomed.example.microsoft.com, has four A RRs for four separate host IP addresses in the example.microsoft.com zone. Two of these IP addresses are for nonlocal networks. The other two IP addresses share a common IP network address but, because IP subnetting is used, represent different physical subnetted network connections based on their custom (nondefault) subnet mask value of 255.255.248.0. These example RRs appear in the following order in the zone:

multihomed IN A 192.168.1.27
multihomed IN A 172.16.22.4
multihomed IN A 10.0.0.14
multihomed IN A 172.16.31.5

If the IP address of the requesting client is 172.16.22.8, both of the IP addresses that match the same IP network as the client, the 172.16.0.0 network, are returned at the top of the answer list to the client. However, in this example, the 172.16.22.4 address is placed ahead of the 172.16.31.5 address because it matches the client IP address down through the 172.16.20.0 subnet address.

The reordered answer list returned by the DNS Server service would be:

multihomed IN A 172.16.22.4
multihomed IN A 172.16.31.5
multihomed IN A 192.168.1.27
multihomed IN A 10.0.0.14

Notes

  • IP subnetting is imposed by using a custom or nondefault subnet mask value with all IP addresses on your network. For more information, see Subnet masks.
  • Local subnet priority supersedes the use of round-robin rotation for multihomed names. When round robin is enabled, however, RRs continue to be rotated using round robin as the secondary method of sorting the response list. For more information on round robin, see Configuring round robin.


Tuning advanced server parameters

When initialized for service, DNS servers use server configuration settings taken from the parameters stated in a boot information file, the registry, and possibly zone information provided through Active Directory integration.

In most situations, the installation defaults are acceptable and should not require modification. However, when needed, you can use the DNS console to tune the following advanced parameters, accommodating special deployment needs and situations.

For making these adjustments, use the Advanced tab in DNS server Properties.

Value | Description
Disable recursion | Determines whether or not the DNS server uses recursion. By default, the DNS Server service is enabled to use recursion. For more information, see Disabling recursion.
BIND secondaries Determines whether to use fast transfer format when transferring a zone to DNS servers running legacy Berkeley Internet Name Domain (BIND) implementations.

By default, all Windows-based DNS servers use a fast zone transfer format, which uses compression and can include multiple records per TCP message during a connected transfer. This format is also compatible with more recent BIND-based DNS servers that run versions 4.9.4 and later.

For more information, see Zone transfer with BIND and other DNS server implementations.
Fail on load if bad zone data Sets the DNS server to parse files strictly.

By default, the DNS Server service logs data errors, ignore any erred data in zone files, and continue to load a zone. This option can be reconfigured using the DNS console so that the DNS Server service logs errors and fails to load a zone file containing records data that is determined to have errors.

For more information, see Checking names and zone data.
Enable round robin Determines whether the DNS server uses round robin to rotate and reorder a list of resource records (RRs) if multiple RRs exist of the same type exisit for a query answer.

By default, the DNS Server service uses round robin. For more information, see Configuring round robin.
Enable netmask ordering Determines whether the DNS server reorders A resource records within the same resource record set in its response to a query based on the IP address of the source of the query.

By default, the DNS Server service uses local subnet priority. For more information, see Prioritizing local subnets.
Secure cache against pollution Determines whether the server attempts to clean up responses to avoid cache pollution. This setting is enabled by default.

By default, DNS servers use a secure response option that eliminates adding unrelated resource records included in a referral answer to their cache. In most cases, any names added in referral answers are typically cached and help expedite the speed of resolving subsequent DNS queries.

With this feature, however, the server can determine that referred names are potentially polluting or insecure and discard them. The server determines whether to cache the name offered in a referral on the basis of whether or not it is part of the exact related DNS domain name tree for which the original queried name was made.

For example, if a query was originally made for "example.microsoft.com" and a referral answer provided a record for a name outside of the "microsoft.com" domain name tree, such as msn.com, then that name would not be cached where this feature is enabled for use.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Notes

  • It is recommended that you use the DNS console to configure these and other server parameter values.
  • Additional advanced parameters can be configured by registry-based configuration. For more information, see Microsoft Windows Deployment and Resource Kits.
  • DNS server parameter key values are stored in the following location in the registry:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

  • DNS zone parameter key values are stored in the following location in the registry:

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\DNS Server

  • When using registry-based configuration, changes are applied to DNS servers only when the service is re-initialized. In these cases, if a value is manually changed directly in the registry, the DNS server must always be restarted for the new value to be used.

    For more information, see To start or stop a DNS server.


Using DNS Security Extensions (DNSSEC)

Windows Server 2003 DNS provides basic support of the DNS Security Extensions (DNSSEC) protocol as defined in RFC 2535. The current feature support allows DNS servers to perform as secondary DNS servers for existing DNSSEC–compliant, secure zones. DNS supports the storing and loading of the DNSSEC-specific resource records (RRs). Currently, a DNS server is not capable of signing zones and resource records (creating cryptographic digital signatures) or validating the SIG RRs. The DNSSEC resource records are KEY, SIG, and NXT. For more information about resource records, see Resource records reference. For more information about RFCs, see DNS RFCs.

Server support for DNSSEC

When loading a zone containing DNSSEC resource records, the DNS server loads these records along with all other types of resource records contained in the zone. When receiving a zone transfer containing DNSSEC resource records (SIG, KEY, NXT), the DNS server writes these records to the zone storage (zone data file or Active Directory) along with all other resource records.

When a DNS server receives a request or response containing DNSSEC resource records, it does not verify the digital signatures but caches the response and uses it for ensuing queries. When a DNS server receives a request for a resource record in a zone also containing DNSSEC resource records, it attaches the appropriate DNSSEC records to the response.

When a signed zone contains resource records for an owner name including a CNAME resource record for that name, the DNS server will return the DNSSEC resource records associated with the owner name and the CNAME resource record's alias name. The DNS server will not suppress the retrieval of the CNAME resource record, and it will not return a SIG resource record for the canonical name. Rather, it will return the SIG resource record for the alias name.

Client support for DNSSEC

The DNS client does not read and store a key for the trusted zone and, consequently, it does not perform any cryptography, authentication, or verification. When a resolver initiates a DNS query and the response contains DNSSEC resource records, programs running on the DNS client will return these records and cache them in the same manner as any other resource records. This is the extent to which XOX DNS clients support DNSSEC. When the DNS client receives the SIG RR relating to the RRset, it will not perform an additional query to obtain the associated KEY record or any other DNSSEC records.

Resolvers do not authenticate resource records by verifying the signature information contained in the SIG resource record. The DNS client does not contain any information to indicate which resource records have been authenticated or to what extent they have been authenticated.

When a resolver receives a response or performs a query operation, it does not recognize the checking disabled (CD) query header bit, which in DNSSEC indicates that the data is authenticated by the server according to its policies, or set the authentic data (AD) query header bit, which in DNSSEC indicates that nonauthenticated data is acceptable to the resolver.

For more information, see To modify DNSSEC configuration and DNSSEC overview.

Note

  • If there is a signing agent running on the DNS server running Windows Server 2003 that signs the zone resource records, this DNS server may also be used as a primary server for DNSSEC-compliant secure zones.


Using Extension Mechanisms for DNS (EDNS0)

Extension Mechanisms for DNS (EDNS0 as defined in RFC 2671) allow DNS requestors to advertise the size of their UDP packets and facilitate the transfer of packets larger than 512 octets, the original DNS restriction for UDP packet size (RFC 1035). When a DNS server receives a request over the UDP Transport Layer, it identifies the requestor's UDP packet size from the OPT resource record (RR) and scales its response to contain as many resource records as are allowed in the maximum UDP packet size specified by the requestor. For more information about resource records, see Resource records reference. For more information about RFCs, see DNS RFCs.

ENDS0 UDP responses

Before a DNS server assumes that the requestor supports EDNS0, the DNS server must receive a query containing an OPT resource record. An OPT record contains no actual DNS data and its contents relate to the UDP Transport Layer message only. The OPT record stores the sender's UDP payload size in its CLASS field and lists the number of octets in the largest UDP payload that the requestor can deliver in the requestor's network.

When the DNS server receives a query containing an OPT record advertising the maximum UDP packet size, it will truncate any UDP response's size larger than the limit specified in the OPT record.

By default, the DNS server includes OPT resource records indicating its UDP maximum in responses to queries containing OPT resource records. For information about modifying the OPT response setting, see To modify EDNS0 configuration.

If the DNS server receives a query that does not contain an OPT resource record, it assumes the requestor's server does not support EDNS0 and will respond to the requestor assuming that the sender does not accept UDP packets larger than 512 octets. In this case, the DNS server will truncate its UDP response size to a maximum of 512 octets.

EDNS0 UDP queries

Before the requesting DNS server sends a query, it checks its cache to identify if the responding DNS server supports EDNS0. If the responding DNS server supports EDNS0, the requesting DNS server attaches an OPT resource record to the additional section of the query it sends. (All queries have five sections: header, question, answer, authority, and additional.) If, according to the requesting DNS server's cache, the responding DNS server does not support EDNS0, the requesting DNS server will not attach an OPT resource record to the query before it is sent. For more information, see To modify UDP message size.

Identifying and caching EDNS0 support

When the DNS server receives a request or response from a host containing an OPT record, the DNS server caches the EDNS version supported by the host (such as EDNS0). If there is no OPT record in a request or response from a host, the DNS server's cache will indicate that the host does not support EDNS0. If the cache already indicates that the host does support ENDS0, then cache will not be changed.

The default value for how long a host's EDNS0 support information is cached is 25200 (one week specified in seconds). This value can be modified in the EDNSCacheTimeout registry entry, in the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dns\Parameters

The range of values allowed is from 3600 (1 hour) to 15724800 (182 days). For information about modifying the EDNS0 cache setting, see To modify EDNS0 configuration.

The DNS server decides that a host does not support EDNS0 when it requests an OPT resource record and receives a response containing one of the following RCODE values in the header:

Name | Value | Description
FORMERR | 1 | Format Error. The name server did not interpret the OPT resource record.
SERVFAIL | 2 | Server Failure. The name server did not process the query because of a problem with the name server.
NOTIMPL | 4 | Not Implemented. The name server does not support the kind of query requested.

(The RCODE field, or response code field, is a 4-bit field set in the header section as part of responses.) In this situation (as a requester), the DNS server identifies that the server does not support EDNS0 and caches this information.

Caution

  • When considering packet sizes, you should take account of the network transmission path's discovered Maximum Transmission Unit (MTU), if this information is available. When configuring the UDP packet size to be larger than 512 octets, remember that the UDP packets must travel through devices other than UDP hosts and these devices, such as routers, may not support UDP packets larger than 512 octets. The maximum UDP packet size should always be compared with the MTU, which in some cases may be smaller. It is recommended that you establish the maximum UDP packet length support for all devices, and configure your UDP hosts for this maximum.

Note

  • EDNS0 refers to the first RFC for EDNS (RFC 2671). Future RFCs for EDNS will be identified by greater numbers, such as EDNS1.


Resources

This section covers:

  • Resource records reference
  • DNS server log reference
  • DNS-related files
  • DNS updated technical information
  • DNS RFCs
  • Top-level domains
  • DNS bibliography


Resource records reference

A DNS database consists of one or more zone files used by the DNS server. Each zone holds a collection of structured resource records, the following of which are supported by the DNS Server service.

Format of DNS resource records

All resource records have a defined format that uses the same top-level fields, as described in the following table.

Field | Description
Owner | Indicates the DNS domain name that owns a resource record. This name is the same as that of the console tree node where a resource record is located.
Time to Live (TTL) For most resource records, this field is optional. It indicates a length of time used by other DNS servers to determine how long to cache information for a record before expiring and discarding it.

For example, most resource records created by the DNS Server service inherit the minimum (default) TTL of 1 hour from the start of authority (SOA) resource record which prevents overlong caching by other DNS servers.

For an individual resource record, you can specify a record-specific TTL that overrides the minimum (default) TTL inherited from the SOA RR. TTL values of zero (0) can also be used for resource records that contain volatile data not to be cached for later use after the current DNS query in progress is completed.

Note

  • In the resource record examples below, the TTL field is omitted wherever it is optional. The TTL field is included in the syntax for each record to indicate where it may be added.
Class | Contains standard mnemonic text indicating the class of the resource record. For example, a setting of "IN" indicates that the resource record belongs to the Internet class, which is the only class supported by Windows Server 2003 DNS. This field is required.
Type | Contains standard mnemonic text indicating the type of resource record. For example, a mnemonic of "A" indicates that the resource record stores host address information. This field is required.
Record-specific data | A required, variable-length field that contains information describing the resource. The format of this information varies according to the type and class of the resource record.

A

Description: Host address (A) resource record. Maps a DNS domain name to an Internet Protocol (IP) version 4 32-bit address. For more information, see RFC 1035.
Syntax:
owner class ttl A IP_v4_address
Example:
host1.example.microsoft.com.     IN  A  127.0.0.1

AAAA

Description: IPv6 host address (AAAA) resource record. Maps a DNS domain name to an Internet Protocol (IP) version 6 128-bit address. For more information, see RFC 1886.
Syntax:
owner class ttl AAAA IP_v6_address
Example:
ipv6_host1.example.microsoft.com.     IN  AAAA  4321:0:1:2:3:4:567:89ab

AFSDB

Description: Andrew File System Database (AFSDB) resource record. Maps a DNS domain name in the server_host_name field to the host name for a server computer of a server subtype. The subtype field can have either of the following recognized and supported values:
  • A value of 1 to indicate that the server is an AFS version 3.0 volume location server for the named AFS cell.
  • A value of 2 to indicate that the server is an authenticated name server holding the cell-root directory node for the server that uses either Open Software Foundation's (OSF) DCE authenticated cell-naming system or HP/Apollo's Network Computing Architecture (NCA).
For more information, see RFC 1183.
Syntax:
owner ttl class AFSDB subtype server_host_name
Example:
example.microsoft.com.   AFSDB   1 afs-server1.example.microsoft.com.

ATMA

Description: Asynchronous Transfer Mode address (ATMA) resource record. Maps a DNS domain name in the owner field to an ATM address referenced in the atm_address field.

For more information, see "ATM Name System Specification Version 1.0" at the ATM Forum FTP site. At the ATM Forum FTP site, download af-saa-0069.000.doc or af-saa-0069.000.rtf.

Note

  • XOX
Syntax:
owner ttl class ATMA atm_address
Example:
atm-host   ATMA   47.0079.00010200000000000000.00a03e000002.00

CNAME

Description: Canonical name (CNAME) resource record. Maps an aliased or alternate DNS domain name in the owner field to a canonical or primary DNS domain name specified in the canonical_name field. The canonical or primary DNS domain name used in the data is required and must resolve to a valid DNS domain name in the namespace.
Syntax:
owner ttl class CNAME canonical_name
Example:
aliasname.example.microsoft.com.   CNAME   truename.example.microsoft.com.

HINFO

Description: Host information (HINFO) resource record. Specifies the type of CPU and operating system in the cpu_type and os_type fields, respectively, for the host DNS domain name in the owner field. Well-known CPU and operating system types that are most often used are noted in RFC 1700. This information can be used by application protocols such as FTP, which use special procedures when communicating with computers of a known CPU and operating system type.
Syntax:
owner ttl class HINFO cpu_type os_type
Example:
my-computer-name.example.microsoft.com.    HINFO   INTEL-386  WIN32

ISDN

Description: Integrated Services Digital Network (ISDN) resource record. Maps a DNS domain name to an ISDN telephone number. Telephone numbers used with this record should follow ITU-T E.163/E.164 international telephone numbering standards, which are compatible with current international phone numbering plans already in use. For more information, see RFC 1183.
Syntax:
owner ttl class ISDN isdn_address sub_address
Example:
my-isdn-host.example.microsoft.com.    ISDN   141555555539699 002

KEY

Description: Public key resource record. Contains a public key that is associated with a zone. In full DNSSEC implementation, resolvers and servers use KEY resource records to authenticate SIG resource records received from a signed zones. KEY resource records are signed by the parent zone, allowing a server that knows a parent zone's public key to discover and verify the child zone's key. Name servers or resolvers receiving resource records from a signed zone obtain the corresponding SIG record then retrieve the zone's KEY record. For more information, see RFC 2535.
Syntax:
owner class KEY protocol digital_signature_algorithm (DSA) public_key
Example:
widgets.microsoft.com IN KEY 0x0000 3 0

MB

Description: Mailbox (MB) resource record. Maps a specified domain mailbox name in the owner field to a mailbox host name in mailbox_hostname. The mailbox host name must be the same as a valid host address (A) resource record already used by a host in the same zone. Additionally, the specified host must have a domain mailbox that accepts mail for the specified owner. For more information, see RFC 1035.
Syntax:
owner ttl class MB mailbox_hostname
Example:
mailbox.example.microsoft.com.    MB   mailhost1.example.microsoft.com

MG

Description: Mail group (MG) resource record. Used to add domain mailboxes, each specified by a mailbox (MB) resource record in the current zone, to the domain mailing group identified by owner in this resource record. Names used in the mailbox_name field must be identical to valid mailbox (MB) resource records already present in the current zone. For more information, see RFC 1035.
Syntax:
owner ttl class MG mailbox_name
Example:
administrator.example.microsoft.com.    MG   mailbox1.example.microsoft.com
                                            mailbox2.example.microsoft.com

MINFO

Description: Mailbox mail list information (MINFO) resource record. Specifies (in responsible_mailbox) a domain mailbox name for a responsible person who maintains a mailing list or mailbox specified in the owner field. The error_mailbox field can also be used to specify a domain mailbox that receives error messages related to this mailing list or mailbox. Mailboxes specified for responsible contacts and error forwarding must be the same as valid mailbox (MB) records that already exist in the current zone. For more information, see RFC 1035.
Syntax:
owner ttl class MINFO responsible_mailbox error_mailbox
Example:
administrator.example.microsoft.com.    MINFO  resp-mbox.example.microsoft.com err-mbox.example.microsoft.com

MR

Description: Mailbox renamed (MR) resource record. Specifies a domain mailbox name in new_renamed_mailbox, the proper rename of an existing mailbox specified in the owner field. An MR resource record is often used as a forwarding entry for a user who has moved to a different mailbox. MR records do not cause additional section processing. For more information, see RFC 1035.
Syntax:
owner ttl class MR new_renamed_mailbox
Example:
old-mbox.example.microsoft.com.    MR  new-renamed-mbox.example.microsoft.com

MX

Description: Mail exchanger (MX) resource record. Provides message routing to a mail exchanger host, as specified in mail_exchanger_host, for mail sent to the domain name specified in the owner field. A 2-digit preference value indicates preferred ordering if multiple exchanger hosts are specified. Each exchanger host must have a corresponding host (A) address resource record in a valid zone. For more information, see RFC 1035.
Syntax: owner ttl class MX preference mail_exchanger_host
Example:
example.microsoft.com.    MX  10 mailserver1.example.microsoft.com

NS

Description: Used to map a DNS domain name as specified in owner to the name of hosts operating DNS servers specified in the name_server_domain_name field.
Syntax: owner ttl IN NS name_server_domain_name
Example:
example.microsoft.com.    IN NS  nameserver1.example.microsoft.com

NXT

Description: Next resource record. NXT resource records indicate the nonexistence of a name in a zone by creating a chain of all of the literal owner names in that zone. They also indicate what resource record types are present for an existing name. For more information, see RFC 2535.
Syntax:
owner class NXT next_domain_name last_record_type NXT
Example:
east.widgets.microsoft.com. IN NXT ftp.widgets.microsoft.com. A NXT

OPT

Description: Option resource record. One OPT resource record can be added to the additional data section of either a DNS request or response. An OPT resource record belongs to a particular transport level message, such as UDP, and not to actual DNS data. Only one OPT resource record is allowed, but not required, per message. For more information, see RFC 2671.
Syntax:
name OPT class ttl rdlen rdata
Example:
null  OPT  IN  1280  0  0

PTR

Description: Pointer (PTR) resource record. Points from the name in owner to another location in the DNS namespace as specified by targeted_domain_name. Often used in special domains such as the in-addr.arpa domain tree to provide reverse lookups of address-to-name mappings. In most cases, each record provides information that points to another DNS domain name location, such as a corresponding host (A) address resource record in a forward lookup zone. For more information, see RFC 1035.
Syntax:
owner ttl class PTR targeted_domain_name
Example:
1.0.0.10.in-addr.arpa.    PTR  host.example.microsoft.com.

RP

Description: Responsible Person (RP) resource record. Specifies the domain mailbox name for a responsible person in mailbox_name. This name is then mapped to a domain name in text_record_name for which (TXT) resource records exist in the same zone. When RP records are used in DNS queries, subsequent queries are used to retrieve associated text (TXT) resource record information. For more information, see RFC 1183.
Syntax:
owner ttl class RP mailbox_name text_record_name
Example:
example.microsoft.com.               RP    admin.example.microsoft.com.  admin-info.example.microsoft.com.
admin-info.example.microsoft.com.    TXT  "Joe Administrator, (555) 555-0110"

RT

Description: Route through (RT) resource record. Provides an intermediate host binding for internal hosts that do not have a direct wide area network (WAN) or external network connection. The RT record is similar to the MX record in that any communication from an internal host is routed through the intermediate_host for the destination DNS domain name specified in the owner field. A 2-digit preference value is used to set priority if multiple intermediate routing hosts are specified. For each intermediate host specified, a corresponding host (A) address resource record is needed in the current zone. For more information, see RFC 1183.
Syntax:
owner ttl class RT preference intermediate_host
Example:
example.microsoft.com.    RT    2 lan-router.example.microsoft.com
                          RT   10 wan-router.example.microsoft.com

SIG

Description: Signature resource record. Encrypts a RRset to a signer's (RRset's zone owner) domain name and a validity interval. For more information, see RFC 2535.
Syntax:
owner class SIG ttl signature_expiration signature_inception key_identifier signer_name{digital_signature}
Example:
widgets.microsoft.com IN SIG 86400 19700101000000 19700101000000 49292

widgets.microsoft.com.{

AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCmfiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM=

}

SOA

Description: Start of authority (SOA) resource record. Indicates the name of origin for the zone and contains the name of the server that is the primary source for information about the zone. It also indicates other basic properties of the zone. The SOA resource record is always first in any standard zone. It indicates the DNS server that either originally created it or is now the primary server for the zone. It is also used to store other properties such as version information and timings that affect zone renewal or expiration. These properties affect how often transfers of the zone are done between servers authoritative for the zone. For more information, see Managing authority records.

Note

  • In the example below, the owner (primary DNS server) is specified as "@" because the domain name is the same as the origin of all data in the zone (example.microsoft.com.). This is a standard notation convention for resource records and is most often seen in the SOA record.
Syntax:
owner class SOA name_server responsible_person (serial_number refresh_interval retry_interval expiration minimum_time_to_live)
Example:
@   IN  SOA     nameserver.example.microsoft.com.  postmaster.example.microsoft.com. (
                               1            ; serial number
                               3600         ; refresh   [1h]
                               600          ; retry     [10m]
                               86400        ; expire    [1d]
                               3600 )       ; min TTL   [1h]

SRV

Description: Service locator (SRV) resource record. Allows multiple servers providing a similar TCP/IP-based service to be located using a single DNS query operation. This record enables you to maintain a list of servers for a well-known server port and transport protocol type ordered by preference for a DNS domain name. For example, in Windows Server 2003 DNS, it provides the means to locate domain controllers that use Lightweight Directory Access Protocol (LDAP) service over TCP port 389.

The purposes of each of the specialized fields used in an SRV resource record are as follows:

  • service A symbolic name for the desired service. For well-known services, a reserved universal symbolic name such as "_telnet" or "_smtp" is defined in RFC 1700. If a well-known service name is not defined in RFC 1700, a local or user-preferred name can be used instead. Some widely used TCP/IP services, notably the Post Office Protocol (POP), do not have a single universal symbolic name. If RFC 1700 assigns a name for a service indicated in this field, the RFC-defined name is the only name that is legal to use. Only locally defined services can be named locally.
  • protocol Indicates the transport protocol type. Typically, this is either TCP or UDP, although any transport protocol named in RFC 1700 can be used.
  • name The DNS domain name referred to by this resource record. The SRV resource record is unique among other DNS record types in that it is not used to perform the search or query.
  • priority Sets the preference for a host specified in the target field. DNS clients that query for SRV resource records attempt to contact the first reachable host of the lowest numbered preference listed here. Although target hosts have the same stated preference value, they can be tried in random order. The range of preference values is 0 to 65535.
  • weight Can be used in addition to preference to provide a load-balancing mechanism where multiple servers are specified in the target field and are all set to the same level of preference. When selecting a target server host among those of equal preference, this value can be used to set an added level of preference that can be used to determine the exact order or balancing of selection for the target hosts used in an answered SRV query. When a non-zero value is used, servers of equal preference are tried in proportion to the weight of this value. The range of values is 1 to 65535. If load balancing is not needed, use a value of 0 in this field to make the record easier to read.
  • port The server port on the target host that provides the service indicated in the service field. The range of port numbers is 0 to 65535, although the number is often a well-known assigned service port number, as specified in RFC 1700. Unassigned ports can be used as needed.
  • target Specifies the DNS domain name of the host that provides the type of service being requested. For each host name used, a corresponding host address (A) resource record in the DNS namespace is required. A single period (.) can be used in this field to indicate authoritatively that the requested service specified in this SRV resource record is not available at this DNS domain name.

For more information, see the Internet draft "A DNS RR for specifying the location of services (DNS SRV)."
Syntax:
service.protocol.name ttl class SRV preference weight port target
Example:
_ldap._tcp._msdcs    SRV  0 0   389 dc1.example.microsoft.com
                   SRV 10 0   389 dc2.example.microsoft.com

TXT

Description: Text (TXT) resource record. Maps a DNS domain name specified in the owner field to a string of characters in text_string serving as descriptive text. For more information, see RFC 1035.
Syntax:
owner ttl class TXT text_string
Example:
example.microsoft.com.    TXT  "This is an example of additional domain name information."

WKS

Description: Well-known service (WKS) resource record. Describes the well-known TCP/IP services supported by a particular protocol on a specific IP address. WKS records provide TCP and UDP availability information for TCP/IP servers. If a server either supports both TCP and UDP for a well-known service or has multiple IP addresses that support a service, then multiple WKS records are used. For more information, see RFC 1035.
Syntax:
owner ttl class WKS address protocol service_list
Example:
example.microsoft.com.    WKS  10.0.0.1 TCP ( telnet smtp ftp )

X25

Description: X.25 (X25) resource record. Maps a DNS domain name in the owner field to a Public Switched Data Network (PSDN) address number specified in psdn_number. PSDN numbers used with this record should follow the X.121 international numbering plan. For more information, see RFC 1183.
Syntax:
owner ttl class X25 psdn_number
Example:
example.microsoft.com.    X25  52204455506


DNS server log reference

The following is a partial list of events recorded in the DNS server log. You can view this log by using the DNS console after the DNS Server service is installed on the server computer. For more information, see To view the DNS server system event log.

Event ID Description
2 The DNS server has started.

This message generally appears at startup when either the server computer is started or the DNS Server service is manually started. For more information, see To start or stop a DNS server.
3 The DNS server has shut down.

This message generally appears when either the server computer is shut down or the DNS Server service is stopped manually.
408 The DNS server could not open socket for address [IPaddress]. Verify that this is a valid IP address for the server computer.

To correct the problem, you can do the following:

  • If the specified IP address is not valid, remove it from the list of restricted interfaces for the server and restart the server. For more information, see To restrict a DNS server to listen only on selected addresses.
  • If the specified IP address is no longer valid and was the only address enabled for the DNS server to use, the server might not have started as a result of this configuration error. To correct this problem, delete the following value from the registry and restart the DNS server:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters\ListenAddress

  • If this is a valid IP address for the server computer, verify that no other application that would attempt to use the same DNS server port (such as another DNS server application) is running. By default, DNS uses TCP port 53.
413 The DNS server will send requests to other DNS servers on a port other than its default port (TCP port 53).

This DNS server is multihomed and has been configured to restrict DNS Server service to only some of its configured IP addresses. For this reason, there is no assurance that DNS queries made by this server to other remote DNS servers will be sent using one of the IP addresses enabled for the DNS server.

This might prevent query answer responses returned by these servers from being received on the DNS port that the server is currently configured to use. To avoid this problem, The DNS server sends queries to other DNS servers using an arbitrary non-DNS port, and the response is received regardless of the IP address used.

If you want to limit the DNS server to using only its configured DNS port for sending queries to other DNS servers, use the DNS console to perform one of the following changes in server properties configuration on the Interfaces tab:

  1. Either select All IP addresses to enable the DNS server to listen on all configured server IP addresses
  2. Or, if you continue to select and use Only the following IP addresses, limit the IP address list to a single server IP address.

For more information, see To restrict a DNS server to listen only on selected addresses.
414 The server computer currently has no primary DNS suffix configured. Its DNS name is currently a single label host name. For example, its currently configured name is "host" rather than "host.example.microsoft.com" or another fully qualified name.

While the DNS server has only a single label name, default resource records created for its configured zones use only this single label name when mapping the host name for this DNS server. This can lead to incorrect and failed referrals when clients and other DNS servers use these records to locate this server by name.

In general, the DNS server should be reconfigured with a full DNS computer name appropriate for its domain or workgroup use on your network. For more information, see To configure the primary DNS suffix for a client computer.
708 The DNS server did not detect any zones of either primary or secondary type. It will run as a caching-only server but will not be authoritative for any zones.

For more information, see Using caching-only servers.
3150 The DNS server wrote a new version of zone [zonename] to file [filename]. You can view the new version number by clicking the Record Data tab.

This event should only appear if the DNS server is configured to operate as a root server. For more information, see DNS-related files.
6527 Zone [zonename] expired before it could obtain a successful zone transfer or update from a master server acting as its source for the zone. The zone has been shut down.

This event ID might appear when the DNS server is configured to host a secondary copy of the zone from another DNS server acting as its source or master server. Verify that this server has network connectivity to its configured master server.

If the problem continues, consider one or more of the following options:

  1. Delete the zone and recreate it, specifying either a different master server, or an updated and corrected IP address for the same master server.

    For more information, see Add and remove zones.

  2. If zone expiration continues, consider adjusting the expire interval.

    For more information, see To adjust the expire interval for a zone.

For more information, see Understanding zones and zone transfer.

For more information about all other messages not described in this topic, refer directly to the message text itself as it appears in the DNS server event log.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Notes

  • Event messages logged by the DNS Client service are logged in System log, and can also be viewed using Event Viewer at the applicable client computer. For more information, see Event Viewer.
  • If needed to troubleshoot persistent problems, you can also enable for use advanced debugging options at the DNS server for obtaining a more detailed log of server activity. For more information, see Using server debug logging options or To view a DNS server debug log file.


DNS-related files

The following files relate to using and configuring DNS servers and clients.

File | Description
Boot | BIND boot configuration file. This file is not created by the DNS console. However, as an optional configuration for the DNS Server service, it can be copied from another DNS server running the Berkeley Internet Name Domain (BIND) server implementation of DNS. To use this file with the DNS Server service, you need to click From file in Server properties. On BIND servers, this file is often called the "named.boot" file.
Cache.dns Used to preload resource records into the DNS server names cache. DNS servers use this file to help locate root servers on either your network or the Internet.

By default, this file contains DNS resource records that prime the local cache of the server with the addresses of authoritative root servers for the Internet. If you are setting up a DNS server to resolve Internet DNS names, the information in this file is required unless you enable the use of another DNS server as a forwarder to resolve these names.

Traffic to the Internet root servers is heavy, but because host names are not usually resolved at this level, the load can be reasonably handled. Instead, the root hints file provides referral information that can be useful during DNS name resolution to redirect a query to other servers that are authoritative for names located beneath the root.

For DNS servers operating privately on your internal network, the DNS console can learn and replace the contents of this file with internal root servers on your network, provided they are reachable through the network when you are setting up and configuring new DNS servers. It can be updated using the DNS console from the Root Hints tab located under the applicable server properties.

This file preloads the server names cache when it is started.
Root.dns | Root zone file. This file can appear at a DNS server if it is configured as a root server for your network.
zone_name.dns | Used when a standard zone (either primary or secondary) is added and configured for the server. Files of this type are not created or used for primary type zones that are directory-integrated, which are stored in the Active Directory database.

These files can be found in the systemroot\System32\Dns folder on the server computer.

Notes

  • For more information about operating a DNS server as a root server, see Updating root hints.
  • For more information on hosting your own DNS presence on the Internet, see Using DNS on the Internet.
  • For more information about configuring DNS servers on your network to use forwarders, see Using forwarders.
  • If you are migrating server files from a BIND server to use with a Windows DNS server, you need to rename these files and copy them to the folder used by the DNS Server service. For more information, see Migrating servers.


DNS updated technical information

Updated technical information for DNS can be obtained by searching technical articles available from Product Support Services at the Microsoft Web site. For more information, see Updated technical information.


DNS RFCs

Request for Comments (RFCs) are an evolving series of reports, proposals for protocols, and protocol standards used by the Internet community. Domain Name System (DNS) specifications are based on approved RFCs published by the Internet Engineering Task Force (IETF) and other working groups.

RFCs for the DNS Server service

The following RFCs contain specifications used to design and implement the DNS Server and Client services:

RFC | Title
1034 | Domain Names — Concepts and Facilities
1035 | Domain Names — Implementation and Specification
1123 | Requirements for Internet Hosts — Application and Support
1886 | DNS Extensions to Support IP Version 6
1995 | Incremental Zone Transfer in DNS
1996 | A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
2136 | Dynamic Updates in the Domain Name System (DNS UPDATE)
2181 | Clarifications to the DNS Specification
2308 | Negative Caching of DNS Queries (DNS NCACHE)
2535 | Domain Name System Security Extensions (DNSSEC)
2671 | Extension Mechanisms for DNS (EDNS0)
2782 | A DNS RR for specifying the location of services (DNS SRV)

Internet drafts for DNS

The following Internet drafts contain specifications used to design and implement the DNS Server and Client services:

File name | Title
Draft-skwan-utf8-dns-02.txt | Using the UTF-8 Character Set in the Domain Name System
Draft-ietf-dhc-dhcp-dns-08.txt | Interaction between DHCP and DNS
Draft-ietf-dnsind-tsig-11.txt | Secret Key Transaction Signatures for DNS (TSIG)
Draft-ietf-dnsind-tkey-00.txt | Secret Key Establishment for DNS (TKEY RR)
Draft-skwan-gss-tsig-04.txt | GSS Algorithm for TSIG (GSS-TSIG)

Other specifications for DNS

The following additional specifications are used to design and implement the DNS Server and Client services:

File name | Title
af-saa-0069.000.doc | ATM Name System Specification version 1.0 This specification is published by the ATM Forum. For more information, you can obtain this specification by downloading it from the ATM Forum FTP site.

Obtaining DNS RFCs and other Internet draft specifications

You can obtain RFCs and other Internet drafts from the RFC Editor Web site. RFCs are classified as one of the following: approved Internet standards, proposed Internet standards (circulated in draft form for review), Internet best practices, or For Your Information (FYI) documents. Internet drafts are not assigned an RFC number but are specifications currently in the proposal stage and generally published by one of the IETF working groups, of which several groups focus on discussion of DNS-related topics.

Notes

  • RFCs 1034 and 1035 define the original DNS standard protocol to support domain name services in a TCP/IP environment. These RFCs describe the protocols in a detailed manner, emphasizing the underlying ideas and techniques used in all DNS implementations.
  • XOX


Top-level domains

The following is a list of the eight top-level domains most often used on the Internet to classify organizations by type when they register a second-level domain name for use. For example, microsoft.com (the second-level domain name registered to Microsoft) is registered in the "com" domain, because this is the top-level domain provided for organizations that do business (commerce) on the Internet.

Top-level name | Description | Used by
arpa | Owned by Advanced Research Project Agency (ARPA). Used to register reverse mapping of Internet Protocol version 4 (IPv4) addresses assigned by the Internet Assigned Number Authority (IANA) to DNS domain names for computers that use those addresses on the Internet. | The in-addr.arpa domain
com | For business and commercial use. | Businesses and corporations
edu | For educational use. | Public and private schools, colleges, and universities
gov | For use by governmental institutions. | Local, state, and federal government agencies
int | Reserved for international use. Currently planned for use in RFC 1886 to register reverse mapping of Internet Protocol version 6 (IPv6) addresses assigned by IANA to DNS domain names in the ip6.int domain for computers that use those addresses on the Internet. For more information about RFCs, see DNS RFCs. | The ip6.int domain
mil | For use by military agencies. | Department of Defense (DoD), U.S. Navy, U.S. Army, U.S. Air Force, and other military agencies
net | For use by organizations that provide large-scale Internet or telephony-based service. | InterNIC, AT&T, and other large-scale Internet and telephone service providers
org | For use by noncommercial, nonprofit organizations. | Churches and charitable institutions

Note

  • In addition to these top-level domains which are all three letters in length, the use of two-letter country/region codes (such as "uk" for United Kingdom) are reserved for use. These country/region codes can also be used in conjunction with the three-letter codes listed above to further specify the country or region of origin for organizations that register names in the Internet DNS namespace.


DNS bibliography

For more information about Domain Name System (DNS) or other DNS server implementations, you can consult the following references:

  • Microsoft Windows Server 2003 Resource Kit. Redmond, Washington: Microsoft Corporation.
  • Microsoft Windows Server 2003 Deployment Kit. Redmond, Washington: Microsoft Corporation.
  • Microsoft Windows 2000 Server Resource Kit. Redmond, Washington: Microsoft Corporation.
  • Lee, T., Davies, J. 2000. Microsoft Windows 2000 TCP/IP Protocols and Services Technical Reference. Redmond, Washington: Microsoft Press.
  • Larson, M. and C. Liu. 2001. DNS on Windows 2000. Sebastopol, California: O'Reilly and Associates, Inc.
  • Wong, W. 2000. Windows 2000 DNS Server. Berkeley, California: Osborne/McGraw-Hill.
  • Albitz, P., Loukides, M. and C. Liu. 1998. DNS and BIND, Fourth Edition. Sebastopol, California: O'Reilly and Associates, Inc.
  • Comer, D. 1995. Internetworking with TCP/IP, Vol. 1, Third Edition. Englewood Cliffs, New Jersey: Prentice Hall.


Troubleshooting

This section covers:

  • Troubleshooting DNS clients
  • Troubleshooting DNS servers
  • Troubleshooting dynamic updates
  • Troubleshooting zone problems


Troubleshooting DNS clients

What problem are you having?

The DNS client received a "Name not found" error message.

Cause: The DNS client computer does not have a valid IP configuration for the network.

Solution: Verify that TCP/IP configuration settings for the client computer are correct, particularly those used for DNS name resolution.

To verify a client IP configuration, use the ipconfig command. In the command output, verify that the client has a valid IP address, subnet mask, and default gateway for the network where it is attached and being used.

If the client does not have a valid TCP/IP configuration, you can either:

  1. For dynamically configured clients, use the ipconfig /renew command to manually force the client to renew its IP address configuration with the DHCP server.
  2. For statically configured clients, modify the client TCP/IP properties to use valid configuration settings or complete its DNS configuration for the network.

See also: Ipconfig; To configure TCP/IP for dynamic addressing; To configure TCP/IP for static addressing; To configure TCP/IP to use DNS; Configuring DNS client settings.

Cause: The client was not able to contact a DNS server because of a network or hardware related failure.

Solution: Verify that the client computer has a valid and functioning network connection. First, check that related client hardware (cables and network adapters) are working properly at the client using basic network and hardware troubleshooting steps.

If the client hardware appears to be prepared and functioning properly, verify that it can ping other computers on the same network.

See also: To test a TCP/IP configuration by using the ping command.

Cause: The DNS client cannot contact its configured DNS servers.

Solution: If the DNS client has basic connectivity to the network, verify that it can contact a preferred (or alternate) DNS server.

To verify whether a client has basic TCP/IP access to the DNS server, first try pinging the preferred DNS server by its IP address.

For example, if the client uses a preferred DNS server of 10.0.0.1, type ping 10.0.0.1 at the command prompt on the client computer. If you are not sure what the IP address is for the preferred DNS server, you can observe it by using the ipconfig command.

For example, at the client computer, type ipconfig /all|more if necessary to pause the display so you can read and note any IP addresses listed in DNS servers for the command output.

If no configured DNS servers respond to a direct pinging of their IP address, it indicates that the source of the problem is more likely a network connectivity problem between the client and the DNS servers. If that is the case, follow basic TCP/IP network troubleshooting steps to fix the problem.

See also: To test a TCP/IP configuration by using the ping command.

Cause: The DNS server is not running or responding to queries.

Solution: If the DNS client can ping the DNS server computer, verify that the DNS server is started and able to listen for and respond to client requests. Try using the nslookup command to test whether the server can respond to DNS clients.

See also: To verify DNS server responsiveness using the nslookup command; To start or stop a DNS server.

Cause: The DNS server the client is using does not have authority for the failed name and cannot locate the authoritative server for this name.

Solution: Confirm whether the DNS domain name the client is trying to resolve is one for which its configured DNS servers are authoritative.

For example, if the client is attempting to resolve the name host.example.microsoft.com, verify that the preferred (or an alternate, if one is being used) DNS server queried by the client loads the authoritative zone where a host (A) resource record (RR) for the failed name should exist.

If the preferred server is authoritative for the failed name and loads the applicable zone, determine whether the zone is missing the appropriate RRs. If needed, add the RRs to the zone.

If the preferred server is not authoritative for the failed name, it indicates that configuration errors at the DNS server are the likely cause. As needed, further troubleshoot the problem at the DNS server.

See also: Manage resource records; Troubleshoot DNS servers.

The DNS client appears to have received a response with stale or incorrect information in it.

Cause: The DNS server the client is using does not have authority for the failed name and is using stale information from its local DNS database.

Solution: Determine whether the DNS server is authoritative for the name and proceed accordingly.

For example, if the client is attempting to resolve the name host.example.microsoft.com, verify that the preferred (or an alternate, if one is being used) DNS server queried by the client loads the authoritative zone where a host (A) resource record (RR) for the failed name should exist.

If the preferred server is authoritative for the name and answered using incorrect data, it indicates that the applicable zone might have outdated or stale information in the applicable RR data. If that is the case, you can add and remove the appropriate RRs in the zone.

Another option where dynamic updates are enabled is to force registration and update at the computer targeted by the query. You can force it to update the registration of its resource records by typing the ipconfig /registerdns command at a command prompt.

If the preferred server is not a direct authority for the queried name, it likely answered the query based on information obtained and cached during an earlier recursive lookup. In this case, you might consider clearing the server names cache. This compels the server to use new recursive queries for this RR data and rebuild its cache contents based on current information.

See also: Manage resource records; Troubleshoot DNS servers; To renew DNS client registration using the ipconfig command; To clear the server names cache.

Cause: The preferred DNS server is a secondary server for the zone containing the targeted name and has outdated information.

Solution: If the server that answered the client is a secondary server for the zone, the version of the zone in use at that server might be stale and need to be updated more often.

As an immediate solution, you can initiate a zone transfer at the secondary server to its master server to update the zone. You might also consider using any of the following to improve the freshness of secondary zone data in the future:

  1. Specify additional master servers for the secondary server to use when refreshing the zone.
  2. Adjust the refresh interval on the zone slightly to decrease the length of time that all authoritative servers for the zone can use the zone before they are required to refresh it.
  3. Configure a notify list at a master server that acts as the zone source for the secondary server and enable it to notify this server when the zone changes.

See also: To initiate a zone transfer at a secondary server; To adjust the refresh interval for a zone; To create and manage a notify list for a zone; Using secondary servers; Understanding zones and zone transfer.

Cause: The name queried was specified in error, either through user input or in a stored client configuration.

Solution: Verify that the name was correctly specified in the application where the name query originated.

In most cases, incorrect data in a positive query response indicates one of three possibilities:

  • An incorrect DNS name was entered at the client by a user.
  • A short unqualified name was used at the client and completed by the local resolver using an unintended DNS suffix.
  • Resource records specified in the query were not updated correctly at the DNS server.

Confirm that the name was not entered in error by the user. Verify the exact set of characters entered by the user when the original DNS query was made or check in application settings, such as for any Internet mail or Web browser configurations that were made.

If the name used in the initial query was unqualified, and not the fully qualified domain name (FQDN), try using the FQDN instead in the client application and repeating the query. If you do, be sure to include the trailing dot (.) at the end of the name to indicate that the name entered is an exact FQDN.

If the FQDN query succeeds and returns correct data in the response, the most likely cause of the problem is a misconfigured DNS domain suffix search list used in the client resolver settings.

If you are using DNS in an environment that does not support dynamic updates, or generally administer zone data manually, you might also want to verify that the RRs involved in answering the query were not entered incorrectly. View them to ensure the record data stored in the zone is correct or modify it accordingly.

See also: To configure TCP/IP to use DNS; To modify an existing resource record in a zone.

Cause: The primary zone might have missing or errored data

Solution: Verify that the primary server for the zone has complete and accurate data.

The most likely cause for a primary DNS server for a zone to have missing or incomplete data is because of a failed update request. It is possible that support for dynamic update has not been fully implemented or configured. To resolve the problem, review the DNS dynamic update protocol (RFC 2136) and any requirements it has for DNS servers and clients that use it.

For directory-integrated zones, it is also possible that the affected records for the errored query have been updated in Active Directory but not replicated to all DNS servers loading the zone. By default, all DNS servers that load zones from Active Directory poll it at a set interval (typically every 15 minutes), and update the zone for any incremental changes to it. In most cases, a DNS update takes no more than 20 minutes to replicate to all DNS servers used in an Active Directory domain environment using default replication settings and reliable high-speed links.

If you have specifically configured your zones to disable dynamic update, keep in mind that you need to manually add and update most types of resource records used in a zone. If this is the case, use the DNS console to view and update the affected records.

Another possibility for the errored data is in whether WINS lookup integration is enabled and used with the zone. If you are using WINS lookup with your zones, verify that WINS is not the source of the errored data.

See also: Troubleshoot dynamic updates; Manage resource records; Managing resource records; To verify WINS as the source for answering a DNS query.

The DNS client appears to be affected by another problem not described above.

Cause: My problem is not described above.

Solution: Search TechNet at the Microsoft Web site (http://www.microsoft.com/) for the latest technical information that could relate to the problem. If necessary, you can obtain information and instructions that pertain to your problem or issue.

If you are connected to the Internet, the latest operating system updates are available at the Microsoft Web site. (http://windowsupdate.microsoft.com/)

To obtain the latest service pack updates for Windows NT Server, see the Microsoft Web site. (http://www.microsoft.com/)

See also: DNS updated technical information; DNS; Microsoft Windows Deployment and Resource Kits.


Troubleshooting DNS servers

What problem are you having?

The DNS server is not responding to clients.

Cause: The DNS server is affected by a network failure.

Solution: Verify that the server computer has a valid functioning network connection. First, check that related client hardware (cables and network adapters) are working properly at the client using basic network and hardware troubleshooting steps.

If the server hardware appears to be prepared and functioning properly, check that it has network connectivity by pinging other computers or routers (such as its default gateway) that are used and available on the same network as the affected DNS servers.

See also: To test a TCP/IP configuration by using the ping command.

Cause: The DNS server is reachable through basic network testing but is not responding to DNS queries from clients.

Solution: If the DNS client can ping the DNS server computer, verify that the DNS server is started and able to listen to and respond to client requests. Try using the nslookup command to test whether the server can respond to DNS clients.

See also: To verify DNS server responsiveness using the nslookup command; To start or stop a DNS server.

Cause: The DNS server has been configured to limit service to a specific list of its configured IP addresses. The IP address originally used in testing its responsiveness is not included in this list.

Solution: If the server was previously configured to restrict the IP addresses for which it responds to queries, it is possible that the IP address being used by clients to contact it is not in the list of restricted IP addresses permitted to provide service to clients.

Try testing the server for a response again, but specify a different IP address known to be in the restricted interfaces list for the server. If the DNS server responds for that address, add the missing server IP address to the list.

See also: To verify DNS server responsiveness using the nslookup command; To restrict a DNS server to listen only on selected addresses.

Cause: The DNS server has been configured to disable the use of its automatically created default reverse lookup zones.

Solution: Verify that automatically created reverse lookup zones have been created for the server or that advanced configuration changes have not been previously made to the server.

By default, DNS servers automatically create the following three standard reverse lookup zones based on Request for Comments (RFC) recommendations:

These zones are created with common IP addresses covered by these zones that are not useful in a reverse lookup search (0.0.0.0, 127.0.0.1, and 255.255.255.255). By being authoritative for the zones corresponding to these addresses, the DNS service avoids unnecessary recursion to root servers in order to perform reverse lookups on these types of IP addresses.

It is possible, although unlikely, that these automatic zones are not created. This is because disabling the creation of these zones involves advanced manual configuration of the server registry by a user.

To verify that these zones have been created, do the following:

  1. Open the DNS console.
  2. From the View menu, click Advanced.
  3. In the console tree, click Reverse Lookup Zones.

    Where?

    • DNS
    • applicable DNS server
    • Reverse Lookup Zones
  4. In the details pane, verify that the following reverse lookup zones are present:
    • 0.in-addr.arpa
    • 127.in-addr.arpa
    • 255.in-addr.arpa

See also: To open the DNS console; DNS RFCs.

Cause: The DNS server is configured to use a non-default service port, such as in an advanced security or firewall configuration.

Solution: Verify that the DNS server is not using a non-standard configuration.

This is a rare but possible cause. By default, the nslookup command sends queries to targeted DNS servers using User Datagram Protocol (UDP) port 53. If the DNS server is located on another network only reachable through an intermediate host (such as a packet-filtering router or proxy server), the DNS server might use a non-standard port to listen for and receive client requests.

If this situation applies, determine whether any intermediate firewall or proxy server configuration is intentionally used to block traffic on well-known service ports used for DNS. If not, you might be able to add such a packet filter onto these configurations to permit traffic to standard DNS ports.

Also, check the DNS server event log to see if Event ID 414 or other critical service-related events have occurred which might indicate why the DNS server is not responding.

See also: DNS server log reference; To view the DNS server system event log; Microsoft Windows Deployment and Resource Kits.

The DNS server does not resolve names correctly.

Cause: The DNS server provides incorrect data for queries it successfully answers.

Solution: Determine the cause of the incorrect data for the DNS server.

Some of the most likely causes include the following:

  • Resource records (RRs) were not dynamically updated in a zone.
  • An error was made when manually adding or modifying static resource records in the zone.
  • Stale resource records in the DNS server database, left from cached lookups or zone records not updated with current information or removed when they are no longer needed.

To help prevent the most common types of problems, be sure to first review best practices for tips and suggestions on deploying and managing your DNS servers. Also, follow and use the checklists appropriate for installing and configuring DNS servers and clients based on your deployment needs.

If you are deploying DNS for Active Directory, note new directory integration features. These features can cause some differences for DNS server defaults when the DNS database is directory-integrated, that differ from those used with traditional file-based storage.

Many DNS server problems start with failed queries at a client, so it is often good to start there and troubleshoot the DNS client first.

See also: Best practices; Checklists; Troubleshoot DNS clients; To modify an existing resource record in a zone; To clear the server names cache; Modifying server defaults.

Cause: The DNS server does not resolve names for computers or services outside of your immediate network, such as those located on external networks or the Internet.

Solution: The server has a problem based on its ability to correctly perform recursion. Recursion is used in most DNS configurations to resolve names that are not located within the configured DNS domain name used by the DNS servers and clients.

If a DNS server fails to resolve a name for which it is not authoritative, the cause is usually a failed recursive query. Recursive queries are used frequently by DNS servers to resolve remote names delegated to other DNS zones and servers.

For recursion to work successfully, all DNS servers used in the path of a recursive query must be able to respond to and forward correct data. If not, a recursive query can fail for any of the following reasons:

  • The recursive query times out before it can be completed.
  • A remote DNS server fails to respond.
  • A remote DNS server provides incorrect data.

If a server fails a recursive query for a remote name, review the following possible causes to troubleshoot the problem. If you do not understand recursion or the DNS query process, review conceptual topics in Help to better understand the issues involved.

See also: How DNS query works.

Cause: The DNS server is not configured to use other DNS servers to assist it in resolving queries.

Solution: Check whether the DNS server can use both forwarders and recursion.

By default, all DNS servers are enabled to use recursion, although the option to disable its use is configurable using the DNS console to modify advanced server options. The other possibility where recursion might be disabled is if the server is configured to use forwarders and recursion has been specifically disabled for that configuration.

Note

  • If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.

See also: To disable recursion on the DNS server; To configure a DNS server to use forwarders.

Cause: Current root hints for the DNS server are not valid.

Solution: Check whether server root hints are valid.

If configured and used correctly, root hints always should point to DNS servers authoritative for the zone containing the domain root and top-level domains.

By default, DNS servers are configured to use root hints appropriate to your deployment, based on the following available choices when using the DNS console to configure a server:

  1. If the DNS server is installed as the first DNS server for your network, it is configured as a root server.

    For this configuration, root hints are disabled at the server because the server is authoritative for the root zone.

  2. If the installed server is an additional DNS server for your network, you can direct the Configure DNS Server Wizard to update its root hints from an existing DNS server on the network.
  3. If you do not have other DNS servers on your network but still need to resolve Internet DNS names, you can use the default root hints file which includes a list of Internet root servers authoritative for the Internet DNS namespace.

See also: To update root hints on the DNS server; Updating root hints.

Cause: The DNS server does not have network connectivity to the root servers.

Solution: Test for connectivity to the root servers.

If root hints appear to be configured correctly, verify that the DNS server used in a failed query can ping its root servers by IP address.

If a ping attempt to one root server fails, it might indicate that an IP address for that root server has changed. Reconfiguration of root servers, however, is uncommon.

A more likely cause is a full loss of network connectivity or in some cases, poor network performance on the intermediate network links between the DNS server and its configured root servers. Follow basic TCP/IP network troubleshooting steps to diagnose connections and determine whether this is the problem.

By default, the DNS service uses a recursive time-out of 15 seconds before failing a recursive query. Under normal network conditions, this time-out does not need to be changed. If performance warrants it, however, you can increase this value.

To review additional performance related information on DNS queries, you can enable and use the DNS server debug log file, Dns.log, which can provide extensive information about some types of service-related events.

See also: To test a TCP/IP configuration by using the ping command; Using server debug logging options; To view a DNS server debug log file; Tuning advanced server parameters.

Cause: Other problems exist with updating DNS server data, such as an issue related to zones or dynamic updates.

Solution: Determine whether the problem is related to zones. As needed, Troubleshoot any issues in this area, such as possible failure of zone transfer.

See also: Troubleshoot dynamic updates; Troubleshoot zone problems.

The DNS server appears to be affected by a problem for reasons not described above.

Cause: My problem is not described above.

Solution: Search TechNet at the Microsoft Web site (http://www.microsoft.com/) for the latest technical information that could relate to the problem. If necessary, you can obtain information and instructions that pertain to your problem or issue.

If you are connected to the Internet, the latest operating system updates are available at the Microsoft Web site. (http://windowsupdate.microsoft.com/)

To obtain the latest service pack updates for Windows NT Server, see the Microsoft Web site. (http://www.microsoft.com/)

See also: DNS updated technical information; DNS; Microsoft Windows Deployment and Resource Kits.


Troubleshooting dynamic updates

What problem are you having?

The DNS client is not performing dynamic updates.

Cause: The client (or its DHCP server) do not support the use of the DNS dynamic update protocol.

Solution: Verify that your clients or servers support the DNS dynamic update protocol.

In order for client computers to be registered and updated dynamically with a DNS server, either:

  1. Install or upgrade client computers to XOX or Windows Server 2003.
  2. Install and use the DHCP Server service on your network to lease client computers.

By default, computers attempt to register and perform dynamic update of their DNS names and IP addresses with a DNS server.

For other types of computers, you can deploy Windows Server 2003 DHCP servers, which can perform proxied registrations and updates as needed for non-dynamic clients.

Notes

  • By default, the DNS client on XOX does not attempt dynamic update over a Remote Access Service (RAS) or virtual private network connection. To modify this configuration, you can modify the advanced TCP/IP settings of the particular network connection or modify the registry. For more information, see To configure TCP/IP to use DNS and the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone named with a single-label name is considered a TLD zone, for example, com, edu, blank, my-company. To configure the DNS client to allow the dynamic update of TLD zones, you can use the Update Top Level Domain Zones policy setting or modify the registry.

See also: Using DNS servers with DHCP.

Cause: The client was not able to register with the DNS server because of intermittent problems with either the DNS server or the network.

Solution: At the client computer, use the ipconfig command as appropriate to retry registration or renewal and update client information with the DNS server.

You can use the ipconfig /regsiterdns command option to manually force a retry of its dynamic registration.

For computers running earlier versions of Windows, you can use the options of the ipconfig command to verify, view, or renew the client TCP/IP configuration details as appropriate.

For example, if the client computer obtains its IP address lease from a DHCP server, you might use the ipconfig /renew command to force it to renew its lease with the DHCP server. This action would then cause the DHCP server to proxy an update request to its configured DNS server on behalf of the client.

If the DHCP server succeeds in performing the proxied update with the DNS server, the result would be updated DNS host name and IP address information for the client computer in the DNS database.

See also: To renew DNS client registration using the ipconfig command; To verify, release, or renew a client address lease.

Cause: The client was not able to register and update with the DNS server because of missing or incomplete DNS configuration.

Solution: Verify that the client is fully and correctly configured for DNS, and update its configuration as needed.

One common cause of the client failing to update with the DNS server is that it does not have a DNS suffix (either a primary suffix or connection-specific suffix) configured. This might result in the client attempting to register an incorrect or unintended DNS domain name.

For example, the client could be attempting to register its short or unqualified computer or host name as a top-level domain name in the root zone. This happens because without a DNS suffix configured for the client computer, it determines the configured short name of a computer (such as host-a) is its fully qualified domain name (FQDN). This only occurs because the computer name does not have a DNS suffix to append to it and qualify the computer name when registering it for the client in DNS.

To update the DNS configuration for a client, either:

  1. Configure a primary DNS suffix at the client computer for static TCP/IP clients.
  2. Configure a connection-specific DNS suffix for use at one of the installed network connections at the client computer.

See also: To configure the primary DNS suffix for a client computer; To configure TCP/IP to use DNS; Install and configure clients; Managing clients.

Cause: The DNS client attempted to update its information with the DNS server but failed because of a problem related to the server.

Solution: If a client can reach its preferred and alternate DNS servers as configured, it is likely that the cause of its failed updates can be found elsewhere.

At Windows-based client computers, you can use Event Viewer to check the System log for any event messages that explain why attempts by the client to dynamically update its host (A) or pointer (PTR) resource records failed.

When reviewing messages in the System log, filter or order the display of all messages to view those that specify DnsApi as the source for the message. Typically, these messages are related to the performance of DNS activities, such as DNS queries or dynamic updates.

A common reason updates might fail for a mobile client is that the DNS server required to accept and perform the update does not respond when the client starts at a remote location on the network. This could be due to network performance issues or might indicate a problem in the underlying design of your network. Where these issues persist or seem likely, you should review your DNS deployment and modify it accordingly.

See also: Event Viewer; Deploying DNS; Dynamic update.

The DNS server is not performing dynamic updates.

Cause: The DNS server does not support dynamic updates.

Solution: Verify that the DNS server used by the client can support the DNS dynamic update protocol, as described in RFC 2136.

Only the Windows 2000 and Windows Server 2003 DNS Server service supports dynamic updates. The DNS Server service provided with Windows NT Server 4.0 does not.

If you are using other DNS servers on your network, verify that they are running a DNS server implementation that supports dynamic updates.

See also: Dynamic update; DNS RFCs.

Cause: The DNS server supports dynamic updates but is not configured to accept them.

Solution: Verify that the primary zone where clients require updates is configured to allow dynamic updates.

The default for a new primary zone is to not accept dynamic updates. At the DNS server that loads the applicable primary zone, modify zone properties to allow updates.

See also: To allow dynamic updates.

Cause: The zone database is not available.

Solution: Verify that the zone is available for update.

First, if necessary, verify that the zone exists. For a standard primary zone, verify that the zone file exists at the server and that the zone is not paused. If you are using Active Directory–integrated zones, verify that the DNS server is running as a domain controller and has access to the Active Directory database where zone data is stored.

Secondary zones do not support dynamic updates. If you are trying to determine which server is the primary server for a standard zone, review zone authority records to determine which server is referenced in both the start of authority (SOA) and name server (NS) resource records for the zone. This is the primary server for the zone which can accept dynamic updates to it.

If you need to, you can use the DNS console to change a secondary zone to become a primary zone so that it can accommodate dynamic updates. However, because standard primary zones use a single-master update model, you can only configure one server to accept dynamic updates for the zone.

If you change the zone type at a secondary server so that it becomes the primary server for that zone, you need to either remove the zone or convert it to another zone type (such as a secondary zone) at the original primary server. Otherwise, zone data would become inconsistent and cause additional problems.

If you want to have more than one DNS server be able to update a zone, it is recommended that you change the zone type so that it becomes Active Directory–integrated. To be able to use this zone type, Active Directory must be installed and the server computer must be promoted to a domain controller.

Once the zone is stored in the directory, other domain controllers can load the zone automatically and be allowed to update it when they are running the DNS Server service. This is because Active Directory supports a multiple (or floating) master update model where more than one computer can process updates to the directory database.

See also: To change the zone type; Add and remove zones; Managing authority records; Active Directory integration; Troubleshooting.

Cause: The DNS server is configured to allow only secure dynamic updates and has a security-related problem.

Solution: Verify that zone or resource record security does not block or prevent dynamic updates at the server.

Secure update can be enabled for directory-integrated zones and their resource records. If secure dynamic update is in effect for a directory-integrated zone, then only users, groups, or computers that have write permissions may add new resource records to the zone. If secure dynamic update is in effect for resource records, then only users, groups, or computers that have write permissions can update these resource records. Consequently, security might block or prevent a DNS client (or its DHCP server) from performing an update of its host (A) and pointer (PTR) resource records.

In most cases, secure dynamic update does not prevent new records from being created or added to a zone, but it does restrict who is given default permissions to update or modify records. Where necessary, you can use the access control list (ACL) editing features available for directory-integrated zones to modify security permissions on a zone or its resource records and enable update by another user, group, or computer.

Typically, this is only needed if the computer requesting the update is different from the one that owns the client records and originally created them.

See also: Secure dynamic update; To modify security for a directory-integrated zone; To modify security for a resource record.

Cause: The DNS server required to perform the updates is not available on the network.

Solution: Verify that the DNS server is available on the network or troubleshoot any further issues as necessary.

See also: Troubleshoot DNS servers.

I am having a different problem related to dynamic updates than those described above.

Cause: My problem is not described above.

Solution: Search TechNet at the Microsoft Web site (http://www.microsoft.com/) for the latest technical information that could relate to the problem. If necessary, you can obtain information and instructions that pertain to your problem or issue.

If you are connected to the Internet, the latest operating system updates are available at the Microsoft Web site. (http://windowsupdate.microsoft.com/)

To obtain the latest service pack updates for Windows NT Server, see the Microsoft Web site. (http://www.microsoft.com/)

See also: DNS updated technical information; DNS; Microsoft Windows Deployment and Resource Kits.


Troubleshooting zone problems

What problem are you having?

I am having a problem related to zone transfers.

Cause: The DNS Server service is stopped or the zone is paused.

Solution: Verify that the master (source) and secondary (destination) DNS servers involved in completing transfer of the zone are both started and that the zone is not paused at either server.

See also: To start or stop a DNS server; To start a zone; Understanding zones and zone transfer.

Cause: The DNS servers used during a transfer do not have network connectivity with each other.

Solution: Eliminate the possibility of a basic network connectivity problem between the two servers.

Using the ping command, ping each DNS server by its IP address from its remote counterpart.

For example, at the source server, use the ping command to test IP connectivity with the destination server. At the destination server, repeat the ping test, substituting the IP address for the source server.

Both ping tests should succeed. If not, investigate and resolve intermediate network connectivity issues.

See also: Testing connections by using ping.

Cause: The serial number is the same at both the source and destination servers. Because the value is the same at both servers, no zone transfer occurs between the servers.

Solution: Using the DNS console, perform the following tasks:

  1. Increase the value of the serial number for the zone at the master server (source) to a number greater than the value at the applicable secondary server (destination).
  2. Once you have increased the serial number at the master server to a higher value than is used currently at the secondary server, initiate zone transfer at the secondary server.

When working within the DNS console, the zone serial number can be viewed from the Start of Authority (SOA) tab in the applicable zone properties. To increase this number in the zone, click Increment.

See also: To modify the start of authority (SOA) record for a zone; To initiate a zone transfer at a secondary server.

Cause: The master server (source) and its targeted secondary server (destination) are having interoperability-related problems.

Solution: Investigate possible causes for any problems related to interoperability between DNS servers running Windows Server 2003 and other DNS server implementations, such as an older version of the Berkeley Internet Name Domain (BIND) distribution.

Older BIND servers use an uncompressed zone transfer format. By default, servers running Windows Server 2003 (and later version BIND servers) use a faster compressed format during zone transfers. To accommodate zone transfer with older BIND servers, you need to change advanced server options at your DNS servers running Windows Server 2003.

Another possible interoperability issue is the use and inclusion of WINS forward lookup (WINS) resource records in a zone or their counterpart, the WINS reverse lookup (WINS-R) resource record used for reverse lookup zones. BIND servers do not recognize these records when they are included in zone data being transferred and can flag these records as bad data, possibly failing the zone transfer.

To prevent these records from being used or included in zone transfers to BIND-based servers and other servers that do not recognize them, select Do not replicate this record when configuring WINS properties at the applicable zone.

See also: Zone transfer with BIND and other DNS server implementations; To enable or disable fast transfer format during zone transfers; Interoperability issues; Using WINS lookup; To enable DNS to use WINS resolution.

Cause: The zone has resource records or other data that cannot be interpreted by the DNS server.

Solution: Verify that the zone does not contain incompatible data, such as unsupported resource records types or data errors.

In most cases, the DNS Server service supports all resource record (RR) types that are approved and required for Internet standard DNS usage.

Also, verify that the server has not been configured in advance to prevent loading a zone when bad data is found and investigate its method for checking names. These settings can be configured using DNS console.

See also: Resource records reference; To prevent loading of a zone when bad data is found ; To change the name-checking method used by the DNS server; Checking names and zone data.

Cause: Authoritative zone data is incorrect.

Solution: If a zone transfer continues to fail, ensure that the zone does not contain nonstandard data.

If you manually edit zone files, be aware that records need to be formatted and used according to standard record usage and formatting guidelines as specified in the Request for Comments (RFCs) for DNS. In most cases, user input and data errors can be avoided if records are added and managed using the DNS console.

To determine if errored zone data is a likely source for a failed zone transfer, look in the DNS server event log for messages. You can also use the nslookup command with the -ls option to simulate and test a zone transfer, while observing the data returned in a terminates before full transfer of the zone is complete.

See also: Nslookup; DNS RFCs.

I am trying to use a zone delegation but it appears to be broken.

Cause: Zone delegations are not configured correctly.

Solution: Review how zone delegations are used and revise your zone configurations as needed.

Zones contain information about DNS domains and subdomains. For each new zone you create, the zone originally begins as a single-node database for one DNS domain. As needed, new subdomain nodes can be added directly below the original (parent) domain and stored as a single zone. Sometimes when new subdomains remain part of the same zone, they are called sub-zones.

If used as sub-zones, new subdomains are retained as part of the zone and replicated and updated along with it as a single entity. You can, however, delegate subdomains away and manage them in their own zones. For each subdomain delegated to its own zone, the parent zone needs to have delegation records added to it.

You can use the New Delegation wizard provided in the DNS console to simplify adding these records.

See also: Delegating Zones; To create a zone delegation; To verify a zone delegation using the nslookup command.

I am having a different zone problem than the ones described above.

Cause: My problem is not described above.

Solution: Search TechNet at the Microsoft Web site (http://www.microsoft.com/) for the latest technical information that could relate to the problem. If necessary, you can obtain information and instructions that pertain to your problem or issue.

If you are connected to the Internet, the latest operating system updates are available at the Microsoft Web site. (http://windowsupdate.microsoft.com/)

To obtain the latest service pack updates for Windows NT Server, see the Microsoft Web site. (http://www.microsoft.com/)

See also: DNS updated technical information; DNS; Microsoft Windows Deployment and Resource Kits.


Troubleshooting Computer Names for the Active Directory Installation Wizard

The error you have experienced while using the Active Directory Installation Wizard does not prevent you from successfully promoting this server to a domain controller. You may continue to promote this server and then correct its DNS configuration following promotion.

In order for this domain controller to be located by other domain members and domain controllers, the Domain Controller Locator DNS records must be added to DNS. It is strongly recommended that your DNS infrastructure allows dynamic updates of Domain Controller Locator DNS records, but your DNS administrator may add these records manually after promotion is completed and the domain controller is rebooted. These records are enumerated in the following location:

systemroot\system32\config\netlogon.dns

Cause

The computer name of this computer contains one or more of the following invalid characters:

{|}~[\]^':;<=>?@!"#$^`()+/,* or a space.

Valid computer name characters include all uppercase letters (A-Z), lowercase letters (a-z), numbers (0-9), and the hyphen (-).

Solution

Quit the wizard, rename the computer, and restart the wizard. For more information about client settings, including computer names, see Configuring DNS client settings.

To rename your computer

  1. Open System in Control Panel.
  2. On the Computer Name tab, click Properties.
  3. In Computer name, type a new name for the computer, and then click OK.

    If the computer is a member of a domain, you will be prompted to provide a user name and user password to rename the computer in the domain.

Notes

  • You must be logged on as an administrator to the local computer to change the computer name.
  • XOX
  • A computer joining a domain must use the name created for it by the network administrator, unless you have a user name and password with rights to create computer accounts.
  • If you supplied a valid user name and password for a domain, the domain membership will be automatically updated with the new computer name.
  • It is recommended that you use computer names that are 15 characters or less. If your computer has TCP/IP networking protocol installed, the computer name can be up to 63 characters long but should only contain the numbers 0-9, the letters A-Z and a-z, and hyphens. You may use other characters, but doing so may prevent other users from finding your computer on the network. If your network is using the Microsoft DNS server, you can use any characters except periods. If other networking protocols are installed without TCP/IP, the name is limited to 15 characters.

    • Before using additional characters, consider the following issues:

    • Some third-party resolver software supports only the characters listed in RFC 1123. If you have any third-party resolver software, that software is probably not able to look up computers with names that have non-standard characters.
    • A DNS server that does not support UTF-8 encoding might accept a zone transfer of a zone containing UTF-8 names, but it cannot write back those names to a zone file or reload those names from a zone file. Therefore, you must not transfer a zone that contains UTF-8 characters to a DNS server that does not support them.
  • If you specify a computer name longer than 15 characters and you want longer names to be recognized by the Active Directory domain, the domain administrator must enable registration of DNS names that are 16 bytes or longer.
  • If your computer is a member of a workgroup, no networking is installed, or TCP/IP is not installed, the computer name cannot be more than 15 characters, and the characters must all be uppercase.


DNS Wizard Help

Using this wizard, you can quickly configure your Domain Name System (DNS) server with the following basic settings:

  • Zones. Names in DNS are created using the hierarchical naming conventions of DNS, and the DNS resource records that are used to locate network resources using DNS are stored in forward and reverse lookup zones. For example, the resource records for all network resources identified with the domain name example.microsoft.com would be stored in a forward lookup zone file named example.microsoft.com.
  • Root hints. Root hints are a list of the DNS servers on the Internet that your DNS servers can use to resolve queries for names it does not know. When a DNS server cannot resolve a name query using its local data, it will send the query to a DNS server using its root hints. These hints are essential for DNS servers attempting to locate and find other DNS servers.
  • Forwarders. Typically, forwarders are DNS servers designated to handle queries for names outside of an internal network. Forwarders resolve a good portion of outgoing DNS queries using cached data and thereby decrease the Internet traffic over the network and the response time for clients. A DNS server is designated as a forwarder by configuring other DNS servers to direct their unresolved queries to this server. If you configure your DNS server with a forwarder, your DNS server will forward queries it cannot answer locally to the forwarder.

    In large networks, forwarders are also used to forward queries from the DNS servers in one network segment to the DNS servers in another network segment.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Choose one of the following configuration options:

Create a forward lookup zone
Select this option for a small network that uses Active Directory or that uses an Internet service provider (ISP) to resolve DNS name queries. Using this option, you can:

  • Create a DNS zone for the DNS domain that corresponds to an Active Directory domain used by your network. For example, if your organization has obtained a DNS domain name for the Internet, such as humongousinsurance.com, you can create a zone for the internal DNS namespace that supports the Active Directory domain for your organization, such as corp.humongousinsurance.com.
  • Create a secondary zone for the DNS zone hosted by a DNS server at your ISP. Computers in your network will use this DNS server to resolve internal network DNS name queries, thereby improving DNS performance within your network.

Create forward and reverse lookup zones
Select this option when adding a DNS server to a large network with an existing DNS infrastructure. Using this option, you can:

  • Create forward and reverse lookup zones to resolve queries for resources in a DNS domain in your DNS namespace.
  • Specify the DNS servers to use as forwarders where name queries that this DNS server cannot answer will be sent.
  • If this DNS server is running on an Active Directory domain controller, you will specify the replication scope for the zones you are creating.
  • Configure dynamic updates for the zones you are creating on this DNS server.

Configure root hints only
Select this option if you are creating a forward-only DNS server or adding root hints to a DNS server that is currently configured with a zone and forwarders.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Choose one of the following zone maintenance options:

This server maintains the zone
Select this option if the DNS server running on this computer will host a primary zone that will contain DNS resource records (RRs) for network resources.

An ISP maintains the zone, and a read-only secondary copy resides on this server
Select this option if the DNS server running on this computer will host a copy of a primary zone (secondary zone) that contains DNS resource records for network resources. The primary zone is hosted on a DNS server at the Internet Service Provider (ISP) used by your organization.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Specify the name for the zone that will be hosted on this DNS server.

The name of a zone is the same as the name of the DNS domain for which the zone is authoritative. Every zone has at least one domain name for which it is authoritative. For example, if your printer server is named print_server.corp.humongousinsurance.com, then it is in the DNS domain corp.humongousinsurance.com and the zone containing the DNS information for the printer server is named corp.humongousinsurance.com.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Choose one of the following zone file options:

Create a new file with this file name
Zone files are DNS zone information stored in a file that is used by the DNS server to answer queries. Usually, the name of the zone file is the same as the name of the zone.

The zone file for the zone you are creating is stored locally on this DNS server and commonly uses a .dns file extension. Zone files are stored in the systemroot\System32\Dns folder on the DNS server.

Use this existing file
If the zone file for the zone you are creating already exists, you can copy it to the systemroot\System32\Dns folder on this computer.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

The following dynamic update options are available in this wizard:

Allow only secure dynamic updates
DNS secure dynamic update is available only for zones that are integrated into Active Directory. Once you directory-integrate a zone, access control list (ACL) editing features are available in the DNS console so you can add or remove users or groups from the ACL for a specified zone or resource record.

Allow both nonsecure and secure dynamic updates
Select this option to enable DNS client computers to add, modify, and delete their resource records in the zone you are adding to this DNS server.

Do not allow dynamic updates
Select this option if you want all additions and modifications to this zone to be made manually.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Choose one of the following options for the DNS server forwarder:

Yes, it should forward queries to DNS servers with the following IP addresses
Select this option if you have designated a specific DNS server in your network to forward all queries for names outside of your network to the Internet. If your company connects to the Internet using an Internet Service Provider (ISP), you may want to forward all queries for names outside of your network to a DNS server at your ISP.

No, it should not forward queries
Select this option if you do not want to forward name queries for names outside of your network to the Internet.

Notes

  • It is common for DNS servers in small– and medium–sized organizations to forward queries to DNS servers hosted by their ISP. To configure a DNS server to forward, you will need the IP address of a DNS server to use as a forwarder. If you are using an ISP, you may have to obtain this address from your ISP.
  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Review the following DNS Help topics once you have finished this wizard:

  • Verify DNS server responsiveness using the nslookup command
  • Manage resource records
  • Verify A resource records exist in DNS
  • Troubleshoot dynamic updates
  • Dynamic update


DNS Wizard Help

Choose one of the following options for creating a forward lookup zone:

Yes, create a forward lookup zone now
Select this option if you want to host a forward lookup zone on this DNS server.

No, don't create a forward lookup zone now
Select this option if you want to add a zone at a later time using the DNS console.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Choose one of the following zone type options:

Primary zone
Select the primary zone option if this is a new zone. If this DNS server is installed on an Active Directory domain controller, then the Active Directory–integrated zone option is available in this wizard.

Secondary zone
Select this option if this is a copy of a zone that is hosted on a different DNS server. A secondary zone offers redundancy for the zones in a network. If you have zones hosted on DNS servers in your network or Internet Service Provider (ISP), you may want to add a secondary zone for one of them on this DNS server.

Stub zone
Select the stub zone option if you want this DNS server to remain aware of any DNS server additions for a child zone it has delegated to another DNS server.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Choose one of the following reverse lookup zone options:

Yes, create a reverse lookup zone now
Select this option if you have applications in your network that use reverse lookup zones to obtain the IP addresses of network resources using their DNS host names.

No, don't create a reverse lookup zone now
Select this option if your network does not use reverse lookup zones.

Notes

  • Reverse lookup zones are not required by DNS or any component in the Windows Server 2003 family.
  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Choose one of the following reverse lookup zone options:

Network ID
Select this option if you know the network ID for this zone.

Reverse lookup zone name
Select this option if you know want to enter the exact zone name for the reverse lookup zone, for example 10.in-addr.arpa.

Notes

  • Reverse lookup zones are located under the in-addr.arpa domain. The in-addr.arpa domain is used in all TCP/IP networks that are based on Internet Protocol version 4 (IPv4) addressing. This wizard automatically assumes that you are using this domain when creating a new reverse lookup zone.
  • If you are installing DNS and configuring reverse lookup zones for an Internet Protocol version 6 (IPv6) network, you can specify an exact zone name in the wizard. This will permit you to create reverse lookup zones that can be used to support IPv6 networks, which uses a different special domain name, the ip6.int domain.
  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Using this wizard, you can configure delegated domains and DNS servers.

  • Delegated domains. The resource records for a subordinate domain can be delegated from the DNS server authoritative for the parent domain to other DNS servers. For example, if the DNS server hosts a zone named corp.microsoft.com, you may delegate the domain name example.corp.microsoft.com to other DNS servers that will then become authoritative for the example.corp.microsoft.com resource records.
  • Name servers. You must specify the DNS servers that are authoritative for the delegated domain.

Notes

  • Creating a delegation configures the parent zone with DNS resource records for the DNS servers authoritative for the delegated zone. This wizard does not configure the DNS servers authoritative for the delegated domain with any zones or resource records. You must ensure that the DNS servers targeted by the delegation are each hosting a zone for the delegated domain name. Name resolution of names in the delegated domain will not work until these zones are created on all delegation DNS servers. For information about adding the delegated zone to these authoritative DNS servers, see Add a forward lookup zone.
  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Specify the name of the domain you want to delegate to another DNS server.

Delegated domain
The name of the domain you are delegating is derived from the name of zone where you are creating the delegation. For example, the delegated domain name example.corp.microsoft.com is derived from the zone corp.microsoft.com.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Specify the DNS name servers that will host the delegated zone:

Server Name

Specify the fully qualified domain name (FQDN) and IP address for each DNS name server that is authoritative for the delegated domain.

Notes

  • After you have finished this wizard, the parent zone from which you are performing delegation will include the resource records needed to identify the DNS servers you specified as authoritative for the delegated domain. You must ensure that the DNS servers to which you are delegating the domain are hosting the zone for the delegated domain. For information about adding the zone to these authoritative DNS servers, see Add a forward lookup zone.
  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Review the following DNS Help topics once you have finished this wizard:

  • Verify a zone delegation using the nslookup command
  • Delegating zones
  • Verify DNS server responsiveness using the nslookup command
  • Manage resource records
  • Verify A resource records exist in DNS


DNSSEC overview

The security extensions made to DNS in DNSSEC (RFC 2535) offer services to perform data origin authentication and integrity checking. These services allow digital signatures to be encrypted using private keys and sent as resource records from DNS servers hosting signed (DNSSEC–compliant) zones to resolvers where the resource records can be authenticated using public keys. Both digital signatures and public keys are added to a signed zone in the form of resource records.

It is important to note that the DNSSEC extensions do not intend to protect a DNS server from security problems but are used as a method of data protection for the domain name data sent using DNS. Both private and public keys are associated with specific zones and not with DNS servers hosting those zones. If the security of DNS servers hosting those zones is breached, then the ability of resolvers to authenticate resource records from those zones remains intact and secure.

Important

  • The features of DNSSEC described here, or in RFC 2535, are not fully supported in Windows Server 2003 DNS. Windows Server 2003 DNS provides "basic support" of DNS Security Extensions (DNSSEC) protocol as defined in RFC 2535. For more information, see Using DNS Security Extensions (DNSSEC).

Authentication

In DNSSEC, each zone has its own public and private key used to encrypt and decrypt digital signatures. An encrypted, or secure, zone is a DNS zone that has both a private and public key. When a RRset in a zone is signed using a private key, resolvers containing the zone's public key can authenticate whether a RRset received from the zone is properly authorized.

By using the zone's private key to sign each RRset in the zone, each domain name in the zone, such as widgets.microsoft.com, has a private key. The digital signature for that RRset is added to the zone in the form of a new resource record, SIG. When a DNS server responds positively to a query for a DNS name, it replies with the requested resource records and the SIG resource record that corresponds to that name. Resolvers aware of the public key associated with the requested name receive the SIG resource record and use the public key to authenticate the resource records. The zone's public key is stored in a new resource record type, KEY. KEY resource records must be provided to the resolver before the resolver can authenticate SIG resource records.

DNSSEC verifies to a resolver that the records it has received from a secure zone actually came from the correct zone. Using DNSSEC, a resolver will verify that the IP address for the domain widgets.microsoft.com truly arrived from the only valid widgets.microsoft.com zone.

Special considerations

There are many special considerations in DNSSEC that use DNSSEC resource records in ways uncommon to conventional resource record use. For more information about RFC 2535, "Domain Name System Security Extensions (DNSSEC)," see DNS RFCs.


DNS Wizard Help

Using this wizard, you can quickly configure a Domain Name System (DNS) zone with the following basic settings.

  • Zones. Names in DNS are created using the hierarchical naming conventions of DNS, and the DNS resource records that are used to locate network resources using DNS are stored in forward and reverse lookup zones. For example, the resource records for all network resources identified with the domain name example.microsoft.com would be stored in a forward lookup zone file named example.microsoft.com.
  • Zone type. This wizard allows you to create one of three zone types: primary zone, secondary zone, and stub zone.
  • Zone name. This wizard allows you to specify the name of the zone you are creating.
  • Zone file. This wizard allows you to specify an existing zone file, or you may choose to have the wizard create one for you.
  • Dynamic update. This wizard allows you to specify how or whether DNS client computers may update their DNS resource records with a DNS server whenever changes occur.
  • Master DNS servers. This wizard allows you to specify the DNS servers from which to copy the zone data that is used in secondary and stub zones.
  • Zone replication scope. This wizard allows you to specify how you would like to replicate Active Directory–integrated zone data.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

This wizard allows you to create a forward or reverse lookup zone. A forward lookup zone is the most common zone type and allows network users and applications to locate network resources according to easy to remember DNS names.

A forward lookup zone contains DNS resource records that map the DNS names of network resources to the IP addresses of the computers hosting the resources. In most DNS queries, clients perform a forward lookup, which is a search based on the DNS name of a network resource. The answer to this type of query is the IP address of the computer hosting the network resource.

The configuration of a reverse lookup zone for identifying network resources is strictly an optional part of the implementation of the DNS standard. You are not required to use reverse lookup zones, although they are used to perform security checks for some networked applications.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Specify the DNS servers from which you want to copy the zone:

IP address
You may list multiple master server IP addresses for this zone. When creating and updating the zone, the DNS server will use the first IP address listed, and use the remaining IP addresses (sequentially) if it cannot contact the first master server.

When you create a secondary zone or stub zone, you copy DNS resource records from a zone hosted on another DNS server. The DNS server hosting the zone from which this DNS server will create its secondary or stub zone is called the secondary or stub zone's master server.

Note

  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Choose one of the following replications options for Active Directory-integrated DNS zone data:

To all DNS servers in the Active Directory forest NameOfForest
Select this option if the zone data should be replicated to all the DNS servers running on domain controllers in all domains of the Active Directory forest. Usually, this is the broadest scope of replication.

To all DNS servers in the Active Directory domain NameOfDomain
Select this option if the zone data should be replicated to all DNS servers running on domain controllers in the specified Active Directory domain. The specified Active Directory domain is the domain hosted by the domain controller on which the DNS server hosting the zone is running. This option is the default setting for Active Directory–integrated DNS zone replication.

To all domain controllers in the Active Directory domain NameOfDomain
Select this option if the zone data should be replicated to all domain controllers in the specified Active Directory domain regardless of whether there are DNS servers running on them.

Important

  • If you want DNS servers to load an Active Directory–integrated DNS zone, this replication scope setting must be selected for that DNS zone.

To all domain controllers specified in the scope of the following application directory partition
Select this option if a DNS application directory partition has already been created and the zone data should be replicated to all the domain controllers specified in the replication scope of the application directory partition. DNS application directory partitions may be created by a member of the Enterprise Admin group.

Notes

  • When deciding which replication option to choose, consider that the broader the replication scope, the greater the network traffic caused by replication. For example, if you choose to have Active Directory–integrated DNS zone data replicated to all DNS servers in the forest, this will produce greater network traffic than replicating the DNS zone data to all DNS servers in a single Active Directory domain in that forest.
  • To open the DNS wizards, see To configure a new DNS server; To add a forward lookup zone; To create a zone delegation.


DNS Wizard Help

Review the following DNS Help topics once you have finished this wizard:

  • Manage resource records
  • Verify DNS server responsiveness using the nslookup command
  • Verify A resource records exist in DNS
  • Troubleshoot dynamic updates
  • Dynamic update


Troubleshooting DNS configuration

Error: This server could not dynamically register domain controller locator (Locator) DNS resource records.

Cause: Registration of the domain controller locator (Locator) DNS resource records did not occur for one or more of the following reasons:

  • The authoritative DNS server for the zone where these records should be registered does not support dynamic updates.
  • The primary DNS zone authoritative for the domain name you specified in the wizard is configured to prevent all dynamic updates.
  • The primary DNS zone authoritative for the domain name you specified in the wizard is configured to prevent all dynamic updates from the server you are promoting.

Solution: Allow dynamic update of the domain controller locator (Locator) DNS resource records by doing one of the following:

  • Migrate the primary zone to a DNS server that supports dynamic updates, such as a DNS server running Windows Server 2003.
  • Configure the primary DNS zone authoritative for the domain name you specified in the wizard to allow all dynamic updates, or all dynamic updates from the server you are promoting.
  • If you are unable to do one of the preceding solutions, delegate the following required DNS zones to a DNS server that supports dynamic updates using the following procedure.
    1. On a DNS server that supports dynamic updates, create the following zones:
      • _msdcs.ActiveDirectoryDomainDNSName
      • _sites.ActiveDirectoryDomainDNSName
      • _tcp.ActiveDirectoryDomainDNSName
      • _udp.ActiveDirectoryDomainDNSName

        • ActiveDirectoryDomainDNSName is the DNS domain name of the Active Directory domain you entered in the wizard. For example, unitedstates.corp.humongousinsurance.com.

    2. Create a delegation from the DNS server that is currently authoritative for the DNS zone with the name you specified in the wizard to the DNS server where you created the new zones in step 1.

Notes

  • If you select the Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server check box in the Active Directory Installation Wizard, the wizard will install and configure the DNS Server service locally and create a DNS zone with the same name as the Active Directory domain name you specified in the wizard. The wizard will also configure the local computer to use the local DNS server as its preferred DNS server, and, if the computer is already configured with a preferred DNS server, the wizard will configure a forwarder on the DNS Server service with the IP address of the prior preferred DNS server.

    If the DNS Server service is currently installed, the wizard will create a DNS zone with the same name as the Active Directory domain name you specified in the Active Directory Installation Wizard. To ensure name resolution for the DNS names in this zone by computers that do not use this DNS server as their preferred DNS server, configure the parent zone with a delegation for the new zone created by the wizard.

  • The Net Logon service on a domain controller registers the DNS resource records required for the domain controller to be located in the network every 24 hours. To initiate the registration performed by Net Logon service manually, type:

    net stop "net logon"

    net start "net logon"

  • The error you have experienced while using the Active Directory Installation Wizard does not prevent you from successfully promoting this server to a domain controller. You may continue to promote this server and then correct its DNS configuration following promotion.
  • In order for this domain controller to be located by other domain members and domain controllers, the domain controller locator (Locator) DNS resource records must be added to DNS. It is recommended that your DNS infrastructure allows dynamic updates of domain controller locator (Locator) DNS resource records, but your DNS administrator may add these records manually after promotion is completed and the domain controller is restarted. These records are enumerated in the following location:

    systemroot\System32\Config\Netlogon.dns

See also: Delegating zones; Migrating from third-party servers using zone transfer; To allow dynamic updates; DNS requirements for installing Active Directory.


Troubleshooting DNS configuration

Error: This server could not dynamically register domain controller locator (Locator) DNS resource records.

Cause: Registration of the domain controller locator (Locator) DNS resource records did not occur for one or more of the following reasons:

  • The authoritative DNS server for the zone where these records should be registered does not support dynamic updates. The name of this server is displayed in the error message's details.
  • The primary DNS zone authoritative for the domain name you specified in the wizard is configured to prevent all dynamic updates. The name of the primary DNS zone authoritative for the domain name you specified is displayed in the error message's details.
  • The primary DNS zone authoritative for the domain name you specified in the wizard is configured to prevent all dynamic updates from the server you are promoting.
  • The DNS zone _msdcs.ActiveDirectoryDomainDNSName which you may have created in preparation for the promotion of this server is configured to prevent all dynamic updates or all dynamic updates from the server you are promoting. This is not a common configuration problem.

    ActiveDirectoryDomainDNSName is the DNS domain name of the Active Directory domain you entered in the wizard. For example, unitedstates.corp.humongousinsurance.com.

Solution: Allow dynamic update of the domain controller locator (Locator) DNS resource records by doing one of the following:

  • Migrate the primary DNS zone authoritative for the domain name you specified in the wizard to a DNS server that supports dynamic updates, such as a DNS server running Windows Server 2003.
  • Configure the primary DNS zone authoritative for the domain name you specified in the wizard to allow all dynamic updates, or all dynamic updates from the server you are promoting.
  • If you are unable to do one of the preceding solutions, do the following:
    1. On a DNS server that supports dynamic updates, such as a DNS server running Windows Server 2003, create a zone with the same name as the Active Directory domain name you specified in the wizard. To do this, you may select the Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server check box in the Active Directory Installation Wizard, or you may use a different server that supports dynamic updates.
    2. Create a delegation from the DNS server that is currently authoritative for the primary DNS zone with the name you specified in the wizard to the DNS server where you created the new zone in step 1.

Notes

  • If you select the Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server check box in the Active Directory Installation Wizard, the wizard will install and configure the DNS Server service locally and create a DNS zone with the same name as the Active Directory domain name you specified in the wizard. The wizard will also configure the local computer to use the local DNS server as its preferred DNS server, and, if the computer is already configured with a preferred DNS server, the wizard will configure a forwarder on the DNS Server service with the IP address of the prior preferred DNS server.

    If the DNS Server service is currently installed, the wizard will create a DNS zone with the same name as the Active Directory domain name you specified in the Active Directory Installation Wizard. To ensure name resolution for the DNS names in this zone by computers that do not use this DNS server as their preferred DNS server, configure the parent zone with a delegation for the new zone created by the wizard.

  • The Net Logon service on a domain controller registers the DNS resource records required for the domain controller to be located in the network every 24 hours. To initiate the registration performed by Net Logon service manually, type:

    net stop "net logon"

    net start "net logon"

  • The error you have experienced while using the Active Directory Installation Wizard does not prevent you from successfully promoting this server to a domain controller. You may continue to promote this server and then correct its DNS configuration following promotion.
  • In order for this domain controller to be located by other domain members and domain controllers, the domain controller locator (Locator) DNS resource records must be added to DNS. It is recommended that your DNS infrastructure allows dynamic updates of domain controller locator (Locator) DNS resource records, but your DNS administrator may add these records manually after promotion is completed and the domain controller is restarted. These records are enumerated in the following location:

    systemroot\System32\Config\Netlogon.dns

See also: Migrating from third-party servers using zone transfer; To allow dynamic updates; Delegating zonesl; DNS requirements for installing Active Directory.


Troubleshooting DNS configuration

Error: The Active Directory Installation Wizard encountered an unexpected error while trying to determine if the DNS server where this domain controller will register its DNS resource records supports the dynamic update protocol.

Notes

  • The error you have experienced while using the Active Directory Installation Wizard does not prevent you from successfully promoting this server to a domain controller. You may continue to promote this server and then correct its DNS configuration following promotion.
  • In order for this domain controller to be located by other domain members and domain controllers, the domain controller locator (Locator) DNS resource records must be added to DNS. It is recommended that your DNS infrastructure allows dynamic updates of domain controller locator (Locator) DNS resource records, but your DNS administrator may add these records manually after promotion is completed and the domain controller is restarted. These records are enumerated in the following location:

    systemroot\System32\Config\Netlogon.dns

See also: DNS requirements for installing Active Directory.


Troubleshooting DNS configuration

Error: The Active Directory Installation Wizard encountered an unexpected error while trying to determine the name and address of the DNS server where this domain controller will register its DNS resource records.

Notes

  • The error you have experienced while using the Active Directory Installation Wizard does not prevent you from successfully promoting this server to a domain controller. You may continue to promote this server and then correct its DNS configuration following promotion.
  • In order for this domain controller to be located by other domain members and domain controllers, the domain controller locator (Locator) DNS resource records must be added to DNS. It is recommended that your DNS infrastructure allows dynamic updates of domain controller locator (Locator) DNS resource records, but your DNS administrator may add these records manually after promotion is completed and the domain controller is restarted. These records are enumerated in the following location:

    systemroot\System32\Config\Netlogon.dns

See also: DNS requirements for installing Active Directory.


Troubleshooting DNS configuration

Error: This server could not dynamically register domain controller locator (Locator) DNS resource records because the DNS servers it uses for name resolution did not find a primary authoritative zone for these resource records.

Cause: The preferred or alternate DNS servers used by this computer for name resolution contain incorrect root hints.

Solution: Update the root hints for the DNS servers.

See also: To update root hints on the DNS server.

Cause: There are incorrect delegations in the DNS zones starting at the root and descending to the zone with same name as the Active Directory domain name you specified.

Solution: Verify DNS zone delegations.

Notes

  • The error you have experienced while using the Active Directory Installation Wizard does not prevent you from successfully promoting this server to a domain controller. You may continue to promote this server and then correct its DNS configuration following promotion.
  • In order for this domain controller to be located by other domain members and domain controllers, the domain controller locator (Locator) DNS resource records must be added to DNS. It is recommended that your DNS infrastructure allows dynamic updates of domain controller locator (Locator) DNS resource records, but your DNS administrator may add these records manually after promotion is completed and the domain controller is restarted. These records are enumerated in the following location:

    systemroot\System32\Config\Netlogon.dns

  • This delegation must be configured to allow name resolution of the zone's namespace within your enterprise.
  • If the parent zone already contains the required delegation, then no additional configuration of the parent zone is required.
  • If the DNS server is configured locally, the network connections of this server may be configured with the local DNS server or any other corporate DNS server as its preferred or alternate DNS servers.

See also: To verify a zone delegation using the nslookup command; To create a zone delegation; Configuring a DNS server list; DNS requirements for installing Active Directory.


Troubleshooting DNS configuration

Error: The DNS zone with the name of the Active Directory domain you specified in the Active Directory Installation Wizard cannot be updated.

Cause: The DNS root zone is authoritative for the Active Directory domain name you specified in the Active Directory Installation Wizard. Active Directory domain controllers will not send dynamic updates to the DNS root zone.

Solution: Install a local DNS server.

  1. In the Active Directory Installation Wizard, click Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server , and then click Next.

    2. This option will install a local DNS server and configure it to host the zone with the same name as the Active Directory domain name you specified in the Active Directory Installation Wizard.

  2. From the root zone, create a delegation to this server for the DNS zone with the same name as the Active Directory domain name.

Notes

  • If you click Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server in the Active Directory Installation Wizard, the wizard will install and configure the DNS Server service locally and create a DNS zone with the same name as the Active Directory domain name you specified in the Active Directory Installation Wizard. The wizard will also configure the local computer to use the local DNS server as its preferred DNS server. If the local computer is configured with a preferred DNS server, the IP address for this preferred DNS server is used to configure a forwarder on the local DNS server.

    If the DNS Server service is currently installed, the wizard will create a DNS zone with the same name as the Active Directory domain name you specified in the Active Directory Installation Wizard. To ensure name resolution for the records in this zone by computers that do not use this DNS server, or other DNS servers authoritative for this zone, as their preferred DNS server, you can configure the parent zone with a delegation for the new zone created by the wizard. You should also configure the TCP/IP properties of this server to point to the local DNS server as the preferred DNS server.

  • The error you have experienced while using the Active Directory Installation Wizard does not prevent you from successfully promoting this server to a domain controller. You may continue to promote this server and then correct its DNS configuration following promotion.
  • In order for this domain controller to be located by other domain members and domain controllers, the domain controller locator (Locator) DNS resource records must be added to DNS. It is recommended that your DNS infrastructure allows dynamic updates of domain controller locator (Locator) DNS resource records, but your DNS administrator may add these records manually after promotion is completed and the domain controller is restarted. These records are enumerated in the following location:

    systemroot\System32\Config\Netlogon.dns

  • This delegation must be configured to allow name resolution of the Active Directory's namespace within your enterprise.
  • The Net Logon service on a domain controller registers the DNS resource records required for the domain controller to be located in the network every 24 hours. To initiate the registration performed by Net Logon service manually, type:

    net stop "net logon"

    net start "net logon"

See also: To create a zone delegation; Configuring a DNS servers list; DNS requirements for installing Active Directory.


Troubleshooting DNS configuration

Error: A DNS server used by this server for name resolution did not respond within the time-out interval.

Cause: The network connection of this server is configured with incorrect IP addresses for its preferred and alternate DNS servers.

Solution: Verify that the network connection of this server is working and that the server is configured with the correct IP addresses of the preferred and alternate DNS servers.

See also: To test a TCP/IP configuration by using the ping command; To configure TCP/IP to use DNS.

Cause: The DNS Server service is not installed or is installed and is not running.

Solution: Verify that the DNS Server service is installed and is running. Do one of the following:

  • If this computer is configured to use a local DNS server, verify that the DNS Server service is installed and is running using the net start command. To do this, at the command prompt, type:

    • net start DNSServer

    If the DNS Server service is installed and running, a message appears indicating that the server is already running. If the DNS Server service is installed but not running, the net start DNSServer command starts the DNS Server service. If the DNS Server service is not installed, a message appears indicating that the server name is invalid.

  • If this computer is configured to use a remote DNS server, use the DNS console to start the DNS Server service.

See also: To start or stop a DNS server; To install a DNS server; DNS requirements for installing Active Directory.

Notes

  • The error you have experienced while using the Active Directory Installation Wizard does not prevent you from successfully promoting this server to a domain controller. You may continue to promote this server and then correct its DNS configuration following promotion.
  • In order for this domain controller to be located by other domain members and domain controllers, the domain controller locator (Locator) DNS resource records must be added to DNS. It is recommended that your DNS infrastructure allows dynamic updates of domain controller locator (Locator) DNS resource records, but your DNS administrator may add these records manually after promotion is completed. These records are enumerated in the following location:

    systemroot\System32\Config\Netlogon.dns